Exception Handling
Exceptions are part of the day-to-day talk in software development teams. Getting more into details, an exception is a response from the system to prevent it to get into an unexpected state.
Bad exception handling in a project would lead development directly to a hole where logs are tremendously hard to read and performance poor.
How to deal with an exception is what we would talk about here. I love to explain this by talking about it as “its natural behavior”.
We should differentiate two kinds here. Exceptions that I as a developer throw and the ones that get raised by the execution of the program.
Let’s talk about the first one. Why should I throw an exception? Simple. Throwing an exception will stop your process. If you have a complex process that will need input with certain properties. Why not check it and, if it doesn’t pass this validation, throw an exception and prevent future problems?
By taking this decision — validate the input — we would save resources and time. In addition, we also can respond with a message showing where the problem is.
This, in addition, could lead clients to know what-to-do. For example, if I’m responding from an API “503 SERVICE UNAVAILABLE” the client could establish that will try later.
Talking about the second ones — the ones that occur due to problems while executing — here we should think about the nature of this failure and how to deal with it. I think the best way to deal with this problem is to let the exception propagate so we can check the log in the future and know what went wrong. We could also talk about one scenario where data isn’t consistent and is causing problems. You can deal with it by validating that data before the process starts as we pointed out in the last paragraph.
As you can see at this point, I’m not a big fan of try-catch blocks, in fact, I like that structure but I’m truly careful of where to use it.
Try-catch blocks are a powerful tool but also dangerous. You should beware of where to use them. We should stand and think about if it’s worth using it before just rushing it thinking that try-catch makes your code error-proof.
Try-catch just help your system deal with situations where an exception is raised, but there’s no magic in this structure, your program has already failed and if it’s a needed element in the process, you can not manage to continue with it, so, what’s the point on making it still work when you know perfectly that the process failed?
Is helpful to make certain parts of your code error-proof in order to make your system able to recover after a non-critical fail. But, there’s no point in forcing your code to deal with situations where you cannot assume an execution problem. It could — in fact — lead you to a bigger problem.
Exceptions are part of the development ecosystem, you should not be afraid of them. Having a good relationship with exceptions and exception handling will give you development superpowers, reducing future problems and avoiding anti-patterns.
Part of a clean code is to correctly use exceptions that allow the program to act when an unwanted situation arrives with efficiency and giving the client information about what went wrong.
