Java Exception Handling Patterns and Antipatterns | Create better software
Vložit
- čas přidán 6. 08. 2024
- Have you ever seen or used a Java application that just cannot handle any exceptions? Join me for a bit to see some examples of horrible antipatterns of Java exception handling that people still do in 2022. I'll also share some better principles by the end. I will show a lot of bad Java code, and some good as well, but the main principles apply to many other languages that use exceptions. Some real-life "war stories" are included as well.
I'll be showing 7 of the worst antipatterns for exception handling, and by the end, I will discuss three main principles to improve your exception handling. Stay tuned for more error handling insights in other videos!
Please click the like button if the video provides you with any value or pleasure, and feel free to use the comments section if you have some feedback for me - always love that! Also, requests for future videos are much welcome. If you disagree with any of my points, do let me know.
Timecodes:
0:00 - Why does exception handling matter
0:40 - The 1st Antipattern to avoid
3:06 - The 2nd Antipattern to avoid
4:38 - The 3rd Antipattern to avoid
6:37 - The 4th Antipattern to avoid
8:30 - The 5th Antipattern to avoid
10:44 - The 6th Antipattern to avoid
11:59 - The 7th Antipattern to avoid
13:20 - So, how should you do it then?
Well explained, thank you!
Thank you!
Newbie to java - this sort of stuff is gold dust. Thank you!
Thank you! I'm glad you enjoyed it!
When found in production code, these are called your "daily WTF?"
Great video. Lessons from battle.
I've seen every bad anti-pattern in production and few good patterns. Can't remember #7, though I've seen crazy finally {} code that simply can't work as I assume was intended.
Great video, dude. I agree wholeheartedly. Whether service calls or batch processes, a single transaction may fail, must clean up, handle exceptions, and (in production) the wider process most often must continue. If a specific exception can be handled at the source cause, then do so. If ignored, there must be a comment in code. Nearly always log.warn. Fatal exceptions either "bubble down" (as I think you call it) or we rethrow a custom RTE of several types. Exceptions are handled at the root. We've got retry queues, dead queues, circuit breakers. Custom exception types generalize cause (although note incoming validation (like 400), integration (like 500, db conn failure), reactive/retry response, business exception, or unexpected RTE in this service), and specify handling, return: retry, fatal, unexpected (stack trace), throttle, 404, etc.
Java is a mix of different paradigms and thus does none well, not even OOP. Some finally{} anti-patterns seem to assume Java has defer sugar, or that for example a failed database connection can be forced to succeed in the finally {} block or that it is a last retry attempt ("hail Mary"). The most recent "daily WTF" is code that seems to believe requireNonNull(x) magically converts null to non-null x (which I believe has been copy pasted a dozen times because it confuses and thus quiets lint warnings). Both checked and unchecked exceptions are another regrettable Java design decision, trying to do multiple paradigms badly. Most developers (even after years of experience) have no idea what to do with exceptions and don't seem to think their ignorance is a problem. Your video is a rare find that explains sensible exception handling.
Haha, true, same experience here. I still cringe when I meet these now and then somewhere.
@@familyshare3724 Yeah, I also deal with monitoring and incident response for the services. As long as you don't deliberately hide exceptions in the code - it's very easy to set up automated responses and good alarms based on them.
I'm very happy that Java is also making Nullpointer exceptions better, they used to be the most common, and most annoying exception, unless good patterns are followed.
@@familyshare3724 Thank you! Happy to hear that, I tried to handle the most common and harmful ones I've seen in short form. Always have to make a bit compromises when making it short.
Great video :) . Can you please create one video to create "Logging Mechanism for Exceptions in Java with proper / appt stack trace for users so that they can debug the exceptions/errors"?
Thanks
Hi, thanks for your comment! Working on something else right now, but always happy to hear ideas for interesting future content. Logging/stack trace might be interesting, I need to just figure out how to make it general enough so it would apply for most who want to watch it. But I will think about this!
@@DevXplaining Thanks. Will be eagerly waiting for it. :)
hmm, I think I was using number 4 antipattern in my projects. I have to fix it. thanks
Cheers, that's not too bad, the first 3 are the worst. I've seen it around a lot. Typically better to be more specific, either let it bubble, or think carefully about why we want to intercept it.
@@DevXplaining yes those three are wierd😂. But for the 4th one, in my projects, some exceptions related to database may throw, I catch them and throw custom internal exception with user friendly explanations . Now I figured out that I can use controller advice in spring and there is no need to catch and rethrow, spring handles it
Oh yes, controller advice can be awesome, because it's systematic: Not dependant on whether you remembered to write the code. Everything is of course a tradeoff - some consider those advice interceptos as magic that is not clear, and avoid them. But I love them, because I love magic - as long as it's documented, simple and clear :)