Menu
Exceptions can have different degrees of impact on a program. For example a program should probably abort if OutOfMemoryException is raised, but it is possible to safely and appropriately handle System.Data.SqlClient.SqlException without putting the program in an unknown state.
I do understand that any exception has the potential to put the program in an unstable state if it is not properly handled. Are there exceptions that should never be handled beyond simply logging and throwing up the stack?
726
We can recover from exceptions by either using try-catch block or throwing exceptions back to the caller. All errors in java are unchecked type. Exceptions include both checked as well as unchecked type. Errors are mostly caused by the environment in which program is running.
You should handle the exception at the lowest possible level. If method can't handle the exception properly you should throw it.
Using a try block, you can implement an exception and handle the error inside an except block. Whenever the code breaks inside a try block, the regular code flow will stop and the control will get switched to the except block for handling the error.
This is a case-by-case theoretical question, so the answer will be just as theoretical. The best answer I've ever heard is, "Don't handle an exception if you don't know how to handle it." Logging a message and throwing the exception up the stack is fine because you've actually done something (even if it's just indicating that an error has occurred). But, catching an error and not throwing it up the stack can result in hidden bugs and difficult debugging sessions.
What we've always done is implement a top-level error handler that will perform generic error handling (like log a message, alert the developers, etc.). All exceptions that are unhandled deeper in the code are at least processed by the top-level handler. The exceptions that can be handled lower in the code certainly are handled where they occur.
Consider the case of looping on a list of email addresses to send a message to a mailing list. An exception could occur if one of the email addresses is not properly formatted, but we don't want a single email address to cause the rest of the processing to fail. By handling the specific exception type that occurs, we can log it (or even mark the email address as invalid) and continue processing the rest of the list.
Bottom Line: Whether or not you handle a given exception type really depends on whether or not your code knows what to do to recover when the exception type occurs.
138
The Framework Design Guidelines cover this pretty completely:
Do not catch System.Exception or System.SystemException in framework code, unless you intend to re-throw.
...
Do not catch System.StackOverflowException.
It is extremely difficult to programmatically handle a stack overflow. You should allow this exception to terminate the process and use debugging to determine the source of the problem.
...
Do not catch System.Runtime.InteropServices.SEHException explicitly.
38
answered Oct 08 '22 15:10
This is probably a different scenario, but any exception that implies a programmer error: NullReferenceException, IndexOutOfRangeException, etc. It means you have a bug in your code and you should fix it rather than handle it.
4
That's highly dependent on your application. Most applications should probably show an error message and die for OutOfMemoryException, but not all - an example is a program called SmartRAM (I think that's the name) that recovers RAM by trying to allocate more and more memory until it gets that exception - this causes Windows to drop all cache in RAM, giving you more free memory.
So it really depends on what you're doing. If you, as the expert on your application, feel like you can safely recover from the exception, then you should.
3
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
