How to write your application to avoid falling into a pitfall
One of the reasons why applications fail when it goes to production is the lack of practices used in error handling.❌ We can generally classify errors into the Runtime and Compile (syntax) errors. At least to run your application, you must make compile-time errors to zero. Again that means if you publish your application to production, there aren’t any compile errors. Again we can divide Runtime errors into the Logics and Exceptions. (🤔actually according to my view🙄)
If your code compiles successfully that doesn’t mean everything is good. 😱There is probability in your application run into error state at the runtime. If it is published to production these runtime errors will be lead to the server error.🤐
As mentioned above, in the runtime we’ll face logic and exceptions. Your application’s logical errors could be identified in the QA process. So logic errors will again return to developers to handle. Until you correct those this will go as a circle.🌀 Also sometimes this time some other errors could be found. So these could handle using exceptions. Still, there may be some errors will be hidden in the source code.
As you feel now, there are errors that slip through the QA stage. The developer is haunted 👻 by those unknown errors from which projects he/she worked.
Let’s see what is the difference between error and exceptions.
Errors,
When an error occurs in the program there is no way to recover the program. So the programmer needs to look at why this happens and do fixes to source code. This error may happen because of unhandled exceptions. So in such situations, exception handling comes into help and lets the application run smoothly without failing.
Yes, you can log errors and see that. ! If there is a pattern in a log with the same error most of the time exception can use to avoid this particular error. (Later about this) 🤫
Error handling best practices,
Simply you can use EXCEPTIONS to handle errors.
Exceptions,
Based on the language there are different ways of handling exceptions. Anyway, these language-specific exceptions can use to handle the situations and keep the application runs smoothly. Exceptions are the medicine 💊 for errors! Yes, this prevents the application falls into the error state.
Exception handling best practices,👍
Put your risky code (code that you know probably returns errors if something happens in-between processes) inside a try block. So you can handle the exception. Remember to get the advantage of an exception hierarchy related to the language.
Now you may feel catch all exceptions and that’s it. No, you can’t do that.🙉 WHY?
That is not the best practices followed by Software Engineers. Since by doing this your application will proceed as nothing happens.
■ And when something went wrong you couldn’t find the root cause of why this happens.
■ You’ll face situations where you couldn’t reproduce that.
■ It’s like walking in dark. It takes much time to find the root cause.
So then what is the use of exceptions?🤔
Exceptions use handle specific situations individually. For example,
In Java, if you divide a number by zero it’ll probably break the application process. So what you can do is catch this error using DivideByZero Exception. What does it mean? Your program can identify a specific divide by zero error. Then the application will do what have to do now? Do you break the flow of the application since this is a kind of error? No. Since you used an exception, it should handle it. So you can just give the user a message that he cannot divide this number using zero and ask to try again with another number. Then application without breaking flow again goes back to the previous processing state, Once user processes again it will run risky code which inside try block. Which is a risky code! Right.?
How to code the application to recover by itself,🔄
As described above now you know using exception we can handle specific situations.
■ So you can show the user-specific feedback.
■ Or even you can code it in a way of recovering auto.
Why using the exception hierarchy is best, [pros of not using a single exception to catch all exceptions]
■ Provide a specific message to the user about what went wrong.
■ Make applications behave differently in different scenarios.
Let’s see an example,
You are doing calculations using retrieved data from the database. So you put those in the try block. And used SQL and Arithmetic exceptions. So first time application failed to fetch data. This situation could be managed easily inside the SQL exception, trying to pull data again. So after pulling data when performing calculations application goes to an arithmetic exception. Since this is an Arithmetic exception you can check logics and do certain operations on default situations. How if you used general one exception? You lost an easy recovering process… Maybe you have to do all processes again since you couldn’t identify which process goes wrong! (Remember time complexity !)
If your application is a complex one?
If your application is using inheritance and modules sometimes errors could throw from those starting points. So you need to structure your application in which places do you gonna handle errors. If you pass errors to inherited points (child classes or sub-modules) you should show the root cause of the error. If not again when it comes to developer’s fixing time you’ll be frustrated.😖 You have to decide who is responsible for handle errors, whether callee, caller or ultimate caller.
So, can it recover always?😳
Most of the time exceptions have much data about the situation. Error codes and descriptions can use to recover the application. BUT,
Hey, 😀 don’t worry too much about uncertainty. Let the logger 👇 do the rest of it.
Use log [advice],💁♂️
You can have a separate database to store logs of all exceptions. Either you handle it or not, save that log into the database.
When you save log it’s good if you specify where does this comes from. I saw this good practice in projects that I worked in, those mentioned the following info with each log record.
Class, Method, Log Level (info, warn, error), Payload, Response, and some other stuff. I think at least those mentioned above are compulsory when saving log records.
More: If you can, it’s good if you could log success code flow scenarios also. I saw the advantages of those practices.
Let’s make easy to handle errors and make our life easier as software engineers. 💪
