Part-1 is here...Part-3 is here...
Exception can be thrown for two reasons
1. Application failure, which includes operational failures, code issues and all other technical issues. (mostly non recoverable by end user)
2. Business validations. (mostly recoverable by end user by changing the input data)
If any failure happened,
we required below information to fix the issue
1. What was the failure?
2. Where it happened?
3. Which circumstance or state or environment?
4. What are the input data?
5. Is this recoverable?
6. Is it necessary to Alert / Escalate to the support people?
Our Exception handling must provide all these details whenever the failure happened.
How do we provide these information?
1. What was the failure?
Do not throw a generic high level exception, provide a more specific Exception class.
2. Where it happened?
Do not throw a generic high level exception, provide a more specific Exception class, if we use the Same exception class in many places differentiates with the Id or message. so we know exactly where the failure happened.
3. Which circumstance or state or environment?
This is very important, many time we programmers do not mind that our program work only in a Conditional state(or environment), so we need to provide this information while throwing exception by id orMessage.
The exception handler (typically a catch block or caller method) would change the state or look foralternate and re-try before throw the exception.
4. What are the input data?
This information is important for Exception handling, most of the time exception could happened by theinput data, throw proper data exception when the failure happened like NullArgumentException
5. Is this recoverable?
Most of the time, we throw Validation Exceptions, these validation exceptions would be recoverable by the end user, so the handling code must know that these exceptions are recoverable exceptions, so we Provide more meaningful information to recover this to the end user.
Secondly this would use to hold the same state or environment for the end user to continue working with the application.
6. Is it necessary to Alert / Escalate to the support people?
Not all the exceptions required admin or support people to be informed, so providing this information to the handler code will alert the admin or support team accordingly.
If we get all the mentioned information without seeing the log, code and trace is consider the better Exception handling.
The Exception handling tips Will be continued…
Exception can be thrown for two reasons
1. Application failure, which includes operational failures, code issues and all other technical issues. (mostly non recoverable by end user)
2. Business validations. (mostly recoverable by end user by changing the input data)
If any failure happened,
we required below information to fix the issue
1. What was the failure?
2. Where it happened?
3. Which circumstance or state or environment?
4. What are the input data?
5. Is this recoverable?
6. Is it necessary to Alert / Escalate to the support people?
Our Exception handling must provide all these details whenever the failure happened.
How do we provide these information?
1. What was the failure?
Do not throw a generic high level exception, provide a more specific Exception class.
2. Where it happened?
Do not throw a generic high level exception, provide a more specific Exception class, if we use the Same exception class in many places differentiates with the Id or message. so we know exactly where the failure happened.
3. Which circumstance or state or environment?
This is very important, many time we programmers do not mind that our program work only in a Conditional state(or environment), so we need to provide this information while throwing exception by id orMessage.
The exception handler (typically a catch block or caller method) would change the state or look foralternate and re-try before throw the exception.
4. What are the input data?
This information is important for Exception handling, most of the time exception could happened by theinput data, throw proper data exception when the failure happened like NullArgumentException
5. Is this recoverable?
Most of the time, we throw Validation Exceptions, these validation exceptions would be recoverable by the end user, so the handling code must know that these exceptions are recoverable exceptions, so we Provide more meaningful information to recover this to the end user.
Secondly this would use to hold the same state or environment for the end user to continue working with the application.
6. Is it necessary to Alert / Escalate to the support people?
Not all the exceptions required admin or support people to be informed, so providing this information to the handler code will alert the admin or support team accordingly.
If we get all the mentioned information without seeing the log, code and trace is consider the better Exception handling.
The Exception handling tips Will be continued…
