Designing steps for Exception Management
Designing Steps for Exception Management
1. Which exceptions to handle?
It’s the first step in exception management strategy to identify exceptions that you want to handle in your system or application(s). Based on the requirement and the nature of the system trying to identify the types of expected exceptions such as
- Exceptions raised by users accessing unauthorized system resources
- Exceptions raised by system failures due to disk, CPU, or memory issues.
- Business exceptions that you want to handle. These are exceptions caused by actions such as violations of business rules.
2. How to handle exceptions?
- Consider consistent approach in exception handling in your system.
- Catch only those exceptions which you want to handle otherwise not.
- Catch code block can be used for:
- Logging the exception
- Cleaning up the resources
- To perform retry the operation to recover from the exception.
- While logging the exception remember not to log confidential information and consider security related requirements.
- You can add relevant extra information with exception like thread, system, or transaction id, etc.
- Use centralized exception handling to log the exception details.
- Sometimes, you can leave the exception and let the centralized exception handler to handle it while sometimes there may be a need to catch and re-throw exception or catch and discard the exceptions.
3. What to log?
- Log exception details considering the target audiences which could be end users, application developers, administrators, and stakeholders.
- provide a user friendly message with the nature of the error, and information on how to recover from it, if possible.
- For developers, log detailed information for diagnosis like where the exception is occurred, type of exception, parameters and other details.
- Similarly understand the needs of administrator and stakeholders and gathered those information.
- And, by default log at least the date and time, machine name, exception source and type, exception message, stack and call traces, application domain name, assembly name and version, thread ID, user details and/or transaction id.
4. Where to log exception?
You can choose centralized database, event log or custom log file or publish the exception to message queue where logging service will be the subscriber and responsible to log the exception.
5. Define Notification strategy?
- Identify the audience who should be notified like support staff, admin or any stakeholder.
- Identify the technology which can be used for sending the notification like email(SMTP) or SMS.
- Evaluate and identify log monitoring systems which provides alert or notification.