- Separate Exception Class for storing custom exceptions to throw.
- Tidy up before throwing exceptions.
- Exceptions should be used for unhandled and not known cases preferably.
- Propagate Exception for problems that cannot be dealt with the code.(Basically done for unchecked exceptions)
When to caught Exception?
When an exception is caught the catching clause must either
- re-throw itself or
- take some action to allow the method that contains it to continue working in some meaningful way.
Note: If we want to keep the program running after handling the exception (and this applies to any error handling scheme not just exceptions) we must leave it in a state that is consistent and knowable. That is to say that the programs must behave properly given its state after the error has been handled.
Catch what you can handle?
Include catch clauses only for errors that a method can actually handle. Ideally a catch clause should either try some other strategy to accomplish the method's goal or, more often, report the error to the end user and return the program to a passive state. Alternatively a catch clause may clean up resources and re-throw the exception, or it can create and throw a new exception containing updated error information for the eventual handler (ConvertExceptions). In all cases decisions are only made by decision making code.
The general idea is that exceptions should include references to the exception that caused them. When a layer catches an exception and throws a new one, the new exception should include a reference to the earlier "cause".
Code that ignores checked exceptions when it doesn't know what to do. We need to throw exceptions and if required we need to handle it at an appropriate level of abstraction.
Abort Retry Ignore
If you wish to continue the operation, you need to (a) know where the exception came from (so you know the context for the data), and (b) have enough information to rebuild that circumstance almost exactly. Where programmers do wish to handle exceptions elegantly, this forces the programmers to code exception-handling very close to the site where the exception would be thrown, making the decision hard-coded into the operation, or face the burden of attempting to rebuild the circumstances of the operation (to the point it can be continued).
Code contracts provide a way to specify preconditions, postconditions, and object invariants in your code. Preconditions are requirements that must be met when entering a method or property. Postconditions describe expectations at the time the method or property code exits. Object invariants describe the expected state for a class that is in a good state002E
Don’t Catch Runtime Exceptions
Catching Exception is sort of like using empty catch block. In this case it is being handled too generically.
The rationale is, some RuntimeExceptions are thrown by the VM for arbitrary reasons (like running out of memory, or stack space). You didn't intend to catch a StackOverflowError?, did you? With that empty catch block? Especially since several real-world VMs tend to get unstable on stack overflow. Bottom line: unless you really know what you're doing and why, DontCatchRuntimeExceptions.
Check the arguments before hand for illegal input and stop them there itself.
Security Door Pattern
it provides public and private two functions – if called with public does the checking (by Bouncer Pattern).
Exceptions Tidy Threads
So one thing you can do is have the thread just stop, but if you do that and it's used some heap space or system resources or toggled some reference counts on something shared, you have a problem. You want to deallocate its resources.
- “Using Statements” in C# can be used
- We should avoid injecting an Exception into another thread's execution.
In essence - Centralized way of error reporting.
some exceptions are for user and some for developer we should differentiate properly and throw accordingly.
Don’t throw Generic Exception
- First Rule: Use Exceptions as they are meant to be used.
- Second Rule: Don’t throw the exceptions itself
You are not gonna Need it?
Don’t keep thing that you don’t need ever (Extreme Programming paradigm)
Subscribe to Coding Today
Get the latest posts delivered right to your inbox