Global Exception Handling in Spring Boot

𝗬𝗼𝘂𝗿 𝗔𝗣𝗜 𝗿𝗲𝘁𝘂𝗿𝗻𝗲𝗱 𝟮𝟬𝟬. 𝗕𝘂𝘁 𝘁𝗵𝗲 𝗿𝗲𝗾𝘂𝗲𝘀𝘁 𝗳𝗮𝗶𝗹𝗲𝗱. 𝗔𝗻𝗱 𝘆𝗼𝘂 𝗰𝗮𝗹𝗹𝗲𝗱 𝘁𝗵𝗮𝘁 𝗮 𝘀𝘂𝗰𝗰𝗲𝘀𝘀. This is one of the most common API mistakes I see. Returning 200 OK for everything then burying the real result in the response body. { "success": false, "message": "User not found" } The client got a 200. But the user wasn’t found. That’s not a success. That’s a lie. 𝗛𝗧𝗧𝗣 𝘀𝘁𝗮𝘁𝘂𝘀 𝗰𝗼𝗱𝗲𝘀 𝗲𝘅𝗶𝘀𝘁 𝗳𝗼𝗿 𝗮 𝗿𝗲𝗮𝘀𝗼𝗻. They’re not decoration. They’re a contract between your API and everyone who consumes it. 𝗧𝗵𝗲 𝗰𝗼𝗱𝗲𝘀 𝘁𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗺𝗮𝘁𝘁𝗲𝗿: • 200 → Success, here’s your data • 201 → Created successfully • 400 → Bad request, fix your input • 401 → Not authenticated • 403 → Authenticated, but not allowed • 404 → Resource doesn’t exist • 409 → Conflict, something already exists • 422 → Validation failed • 500 → Server broke, not the client’s fault 𝗪𝗵𝗲𝗻 𝘆𝗼𝘂 𝗿𝗲𝘁𝘂𝗿𝗻 𝘁𝗵𝗲 𝘄𝗿𝗼𝗻𝗴 𝘀𝘁𝗮𝘁𝘂𝘀 𝗰𝗼𝗱𝗲: • Frontend devs write broken error handling • Mobile apps show wrong messages to users • Debugging takes twice as long • Your API becomes unpredictable 𝗔 𝗴𝗼𝗼𝗱 𝗔𝗣𝗜 𝘂𝘀𝗲𝘀 𝘀𝘁𝗮𝘁𝘂𝘀 𝗰𝗼𝗱𝗲𝘀 𝗮𝗻𝗱 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗲 𝗯𝗼𝗱𝗶𝗲𝘀 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿. The status code tells you what happened. The body tells you why. { "status": 404, "message": "User not found" } { "status": 422, "message": "Phone number is required" } Clear enough to debug. Careful enough not to expose sensitive internals. 𝗗𝗷𝗮𝗻𝗴𝗼 𝗥𝗘𝗦𝗧 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 𝗺𝗮𝗸𝗲𝘀 𝘁𝗵𝗶𝘀 𝗲𝗮𝘀𝘆. No excuses. 𝗨𝘀𝗲 𝘀𝘁𝗮𝘁𝘂𝘀 𝗰𝗼𝗱𝗲𝘀 𝗹𝗶𝗸𝗲 𝘆𝗼𝘂 𝗺𝗲𝗮𝗻 𝘁𝗵𝗲𝗺. Your API is a conversation. Make sure it’s saying the right thing. #Django #Python #BackendDevelopment #APIDesign #WebDevelopment #SoftwareEngineering

𝗛𝗼𝘄 𝗚𝗮𝗿𝗯𝗮𝗴𝗲 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝗪𝗼𝗿𝗸𝘀 𝗶𝗻 𝗡𝗼𝗱𝗲.𝗷𝘀 As developers, we often focus on writing efficient code—but what about memory management behind the scenes? In 𝗡𝗼𝗱𝗲.𝗷𝘀, garbage collection (GC) is handled automatically by the 𝗩𝟴 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗲𝗻𝗴𝗶𝗻𝗲, so you don’t need to manually free memory like in languages such as C or C++. But understanding how it works can help you write more optimized and scalable applications. 𝗞𝗲𝘆 𝗖𝗼𝗻𝗰𝗲𝗽𝘁𝘀: 𝟭. 𝗠𝗲𝗺𝗼𝗿𝘆 𝗔𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻 Whenever you create variables, objects, or functions, memory is allocated in two main areas: Stack→ Stores primitive values and references Heap→ Stores objects and complex data 𝟮. 𝗚𝗮𝗿𝗯𝗮𝗴𝗲 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 (𝗠𝗮𝗿𝗸-𝗮𝗻𝗱-𝗦𝘄𝗲𝗲𝗽) V8 uses a technique called Mark-and-Sweep: * It starts from “root” objects (global scope) * Marks all reachable objects * Unreachable objects are considered garbage * Then, it sweeps (removes) them from memory 𝟯. 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗚𝗮𝗿𝗯𝗮𝗴𝗲 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 Not all objects live the same lifespan: Young Generation (New Space) → Short-lived objects Old Generation (Old Space) → Long-lived objects Objects that survive multiple GC cycles get promoted to the Old Generation. 𝟰. 𝗠𝗶𝗻𝗼𝗿 & 𝗠𝗮𝗷𝗼𝗿 𝗚𝗖 Minor GC (Scavenge)→ Fast cleanup of short-lived objects Major GC (Mark-Sweep / Mark-Compact) → Handles long-lived objects but is more expensive 𝟱. 𝗦𝘁𝗼𝗽-𝘁𝗵𝗲-𝗪𝗼𝗿𝗹𝗱 During GC, execution pauses briefly. Modern V8 minimizes this with optimizations like incremental and concurrent GC. 𝗖𝗼𝗺𝗺𝗼𝗻 𝗠𝗲𝗺𝗼𝗿𝘆 𝗜𝘀𝘀𝘂𝗲𝘀: * Memory leaks due to unused references * Global variables holding data unnecessarily * Closures retaining large objects 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀: * Avoid global variables * Clean up event listeners and timers * Use streams for large data processing * Monitor memory using tools like Chrome DevTools or `--inspect` Understanding GC = Writing better, faster, and scalable applications #NodeJS #JavaScript #BackendDevelopment #V8 #Performance #WebDevelopment

Most of the inbound I'm getting right now involves some version of "how do we make our APIs work for AI agents." The answer keeps coming back to the same thing: typed, structured interfaces that tell a machine exactly how to call your API. Postman just shipped SDK generation in 6 languages. You point it at a collection or OpenAPI spec and get production-ready client libraries in TypeScript, Python, Java, Go, C#, and PHP. The part that matters: agents don't read your docs the way a human does. They need SDKs. That's the integration layer. https://lnkd.in/evn_QS75

🚀 10 cURL Commands Every Backend Developer Should Know You’re debugging APIs the slow way. And yeah — that’s costing you hours every week. I’ve seen developers spend 30–40 mins debugging something that takes 30 seconds with cURL. So here are 10 cURL commands that separate beginners from real backend engineers 👇 Here are 10 commands you’ll actually use 👇 ⚡ 1. Basic GET 👉 curl https://lnkd.in/ghmyBe6g ⚡ 2. Add headers (Auth) 👉 curl -H "Authorization: Bearer TOKEN" https://lnkd.in/ghmyBe6g ⚡ 3. POST JSON 👉 curl -X POST https://lnkd.in/ghmyBe6g  -H "Content-Type: application/json" -d '{"name":"Vivek"}' ⚡ 4. Update (PUT) 👉 curl -X PUT https://lnkd.in/g4q-PGzz  -d '{"name":"Updated"}' ⚡ 5. DELETE 👉 curl -X DELETE https://lnkd.in/g4q-PGzz ⚡ 6. Query params 👉 curl "https://lnkd.in/g2erKS-K " ⚡ 7. Debug (verbose) 👉 curl -v https://api.example.com ⚡ 8. Headers only (underrated) 👉 curl -I https://api.example.com ⚡ 9. Save response 👉 curl -o data.json https://lnkd.in/gWQwUqCU ⚡ 10. File upload 👉 curl -X POST https://lnkd.in/gQVadd_t  -F "file=@image.png" 💡 Bonus: 👉 curl --compressed https://api.example.com ⚠️ Hard truth: Postman makes you comfortable. cURL makes you dangerous. 📌 If you found this useful: Save it. You’ll need it during debugging. 💬 Comment: Which cURL command do you use daily? 🔁 Follow for more backend + system design content #BackendDevelopment #WebDevelopment #SoftwareEngineering #APIs #SystemDesign

async/await didn't make your code faster. It just made the slowness harder to see. ───────────────────────── Most devs write this and ship it with confidence: const user = await getUser(id) const posts = await getPosts(id) const comments = await getComments(id) Clean. Readable. And quietly costing you 3x the wait time. ───────────────────────── Here's what's actually happening under the hood 👇 async/await is syntax sugar over Promises. Your linear-looking code compiles into a Promise chain. await doesn't block the thread — it pauses that function and resumes it later. Which means: you can run things in parallel. You're just choosing not to. ───────────────────────── The sequential trap When you await three independent requests in a row, you're making them wait for each other — for no reason. Total time = request1 + request2 + request3 On a slow network, that gap is seconds, not milliseconds. ───────────────────────── The fix: Promise.all const [user, posts, comments] = await Promise.all([ getUser(id), getPosts(id), getComments(id) ]) Total time = slowest request only. ───────────────────────── When one failure shouldn't kill the rest: Promise.allSettled Promise.all fails fast — one rejection kills everything. Promise.allSettled lets every Promise finish and returns each result individually. Use it when partial failure is acceptable. ───────────────────────── The error handling gap nobody talks about A floating Promise that rejects has nowhere to go. No catch. No log. Silent failure in production. Rule: every Promise either gets awaited inside a try/catch, or gets a .catch() attached. No exceptions. ───────────────────────── One question that saves you every time: Before writing a second await — ask yourself: Does this actually need to wait for the previous one? If the answer is no, run them together. ───────────────────────── This post took me 5 seconds to write and 2 years of production bugs to learn. If it saves you the same bugs — repost it for your team ♻️ #JavaScript #WebPerformance #FrontendDevelopment #WebDev #Programming

Most developers use JSON every day. Almost none know how to build a parser from scratch. 🤯 Here's a step-by-step blueprint to build your own JSON Parser 👇 🔴 𝗦𝘁𝗲𝗽 𝟭 — 𝗟𝗲𝘅𝗶𝗰𝗮𝗹 𝗔𝗻𝗮𝗹𝘆𝘀𝗶𝘀 (𝗧𝗼𝗸𝗲𝗻𝗶𝘇𝗲𝗿) ∟ Iterate character by character through raw JSON string ∟ Ignore whitespace — spaces, tabs, newlines ∟ Emit foundational tokens: { } [ ] : , 🟠 𝗦𝘁𝗲𝗽 𝟮 — 𝗧𝗼𝗸𝗲𝗻𝗶𝘇𝗶𝗻𝗴 𝗦𝘁𝗿𝗶𝗻𝗴𝘀 ∟ When you hit " — start accumulating string ∟ Support escape characters: \n \t \" ∟ Throw syntax error if input ends before closing quote ⚠️ 🟡 𝗦𝘁𝗲𝗽 𝟯 — 𝗧𝗼𝗸𝗲𝗻𝗶𝘇𝗶𝗻𝗴 𝗣𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲𝘀 ∟ Detect literals: true false null ∟ Aggregate digits, negatives, decimals & exponents for numbers ∟ Emit structured primitive tokens to continuous list/array 🟢 𝗦𝘁𝗲𝗽 𝟰 — 𝗦𝘆𝗻𝘁𝗮𝗰𝘁𝗶𝗰 𝗔𝗻𝗮𝗹𝘆𝘀𝗶𝘀 (𝗣𝗮𝗿𝘀𝗲𝗿) ∟ Take token array & create a Recursive Descent Parser ∟ Read first token — figure out if it's Object, Array or Primitive ∟ Advance token index recursively to build Abstract Syntax Tree 🌳 🔵 𝗦𝘁𝗲𝗽 𝟱 — 𝗣𝗮𝗿𝘀𝗶𝗻𝗴 𝗔𝗿𝗿𝗮𝘆𝘀 ∟ Start on [ — loop over contents & call parseValue() ∟ Expect & consume commas between parsed array elements ∟ Return built array data structure on reading terminal ] 🟣 𝗦𝘁𝗲𝗽 𝟲 — 𝗣𝗮𝗿𝘀𝗶𝗻𝗴 𝗢𝗯𝗷𝗲𝗰𝘁𝘀 ∟ Start on { — parse string token as Object Key ∟ Expect & consume : colon token ∟ Call parseValue() recursively to assign property values ∟ Expect commas between pairs, return native Object on } ✅ This is what happens behind the scenes every time you call: JSON.parse('{"name": "dev"}') Understanding how tools work makes you a 10x better developer. 🧠 Now go build it. 💪 Save this 🔖 — share it with a developer who loves going deep. Follow for daily backend & coding blueprints. 💡 #Programming #Coding #JavaScript #SoftwareEngineering #ComputerScience #Backend #WebDevelopment #Tech #LearnToCode #Developer

The most overqualified code in your codebase returns undefined. It has a name borrowed from systems programming. It ships in every serious TypeScript project. It gets nodded at in code reviews. 1. Noop A function whose only job is to not be undefined. Pass it as a default prop, a fallback callback, a stub in tests. Call it do Nothing. const noop = () => undefined 2. Identity Returns exactly what you gave it. Useful as a default transform — pass it where a mapper is optional and you don't want to map. const identity = (x: T): T => x 3. Nonce A nonce is a number your server/ client generates fresh for every single request/ response. Not stored. Not reused. Gone after that one exchange. const nonce = () => Math.random().toString(36).slice(2) 4. Silent Swallows every error whole. Legitimate for analytics pings where failure genuinely doesn't matter. The name at least warns you — most people just don't believe it. const silent = async ( fn: () => Promise ) => { try { await fn() } catch (_) {} } 5. Defer Runs something after the current call stack clears. Genuinely useful for unblocking rendering. You didn't solve the problem — you scheduled it for later and shipped. const defer = ( fn: () => void ) => setTimeout(fn, 0) #typescript #react #javascript #softwareengineering #webdev

I stopped using if-else… and my code got 10x better. Sounds dramatic? Maybe. But hear me out. Every time I had to handle different behaviors — Payment methods, notifications, user roles — my code looked like this: if ($type == 'upi') { ... } elseif ($type == 'card') { ... } elseif ($type == 'wallet') { ... } It worked. But it didn’t scale. And it got messy… fast. Then I actually understood Polymorphism. interface Payment { public function pay(); } class UPI implements Payment { public function pay() { return "Paid via UPI"; } } class Card implements Payment { public function pay() { return "Paid via Card"; } } function processPayment(Payment $payment) { return $payment->pay(); } No conditions. No chaos. Just clean, extensible code. 💡 Add a new payment method? Create a new class. That’s it. No touching old code. No breaking things. That’s when it hit me — Polymorphism isn’t a concept. It’s a mindset. 👉 Stop asking: “Which type is this?” 👉 Start designing: “How should this behave?” — If you're still writing long if-else chains… you're one abstraction away from better code. Have you had that “this changes everything” moment in coding? 👇 #php #laravel #oop #cleanCode #webdevelopment #programming #developers

BigDecimal .equals() trap — 2-hour debug story new BigDecimal("10.00").equals(new BigDecimal("10.0")) → false. If your payment system compares amounts with .equals(), you already have a bug. You just haven't seen the ticket yet. Here's how I learned this — 4 PM on a tired Tuesday last month. A unit test asserting that a calculated total matched an expected value. Values looked identical on screen. Test kept failing. Same number. Different scale. equals() compares both value AND scale. The fix: compareTo() == 0 I had read this in Effective Java, Item 62. I had caught it in code review on someone else's code three months earlier. When I wrote the test myself at 4 PM, I still forgot. Two real lessons: 1. BigDecimal is quietly vicious. Scale matters. Rounding mode matters. And new BigDecimal(0.1) is NOT the same as new BigDecimal("0.1") — the first one is 0.1000000000000000055511151231257827021181583404541015625. Your unit test won't catch it if both sides use the double constructor. 2. Knowing the rule and using the rule are different skills. Reviewing someone else's code with a fresh brain is easy. Catching your own mistake at end of day is not. This is why code review exists — we're blind to our own bugs. I keep a 60-second checklist now for anything money-adjacent: → BigDecimal with String constructor ONLY → compareTo, never equals → RoundingMode always explicit (HALF_EVEN for banking) → No float or double anywhere near currency → Scale set explicitly at the boundary What's the smallest bug that cost you the most time? #Java #BackendDevelopment

🛠️ 𝐈𝐦𝐩𝐥𝐞𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧: 𝐏𝐚𝐠𝐢𝐧𝐚𝐭𝐢𝐨𝐧 & 𝐒𝐨𝐫𝐭𝐢𝐧𝐠 𝐢𝐧 𝐚 𝐒𝐩𝐫𝐢𝐧𝐠 𝐁𝐨𝐨𝐭 A𝐏𝐈 When working with large datasets, returning everything at once is never a good idea. It increases response time, impacts performance, and doesn’t scale well. 🔍 𝐏𝐫𝐨𝐛𝐥𝐞𝐦 My API was returning a huge dataset in a single response → leading to slow performance and inefficient data handling. 💡 𝐖𝐡𝐚𝐭 𝐭𝐡𝐢𝐬 𝐢𝐦𝐩𝐫𝐨𝐯𝐞𝐬 ✔️ Breaks large data into manageable pages ✔️ Reduces response payload ✔️ Improves API performance ✔️ Allows dynamic sorting ✔️ Supports field-based sorting ascending order 🧠 𝐊𝐞𝐲 𝐭𝐚𝐤𝐞𝐚𝐰𝐚𝐲 Backend development is not just about returning data it’s about returning it efficiently and responsibly. 📈 𝐑𝐞𝐚𝐥-𝐰𝐨𝐫𝐥𝐝 𝐢𝐦𝐩𝐚𝐜𝐭 Pagination combined with sorting is essential for building scalable APIs, especially when handling large datasets in production systems 🔽 Adding the implementation below for reference #SpringBoot #Java #BackendDevelopment #APIDesign #SoftwareEngineering