|
When creating big applications(even medium apps) there are so many different kinds of exceptions that can come?
How to go about handling them?
And how do prioritize these exceptions?
(We just cannot write a 100 try-catches,can we?)
|
|
|
|
|
You should never be trying to handle exceptions from the whole application in the same place (apart from a last ditch catch-all to put up a message and log a bug report).
In any individual operation, there should be only one or two possible exceptions that can be thrown. You should catch and handle them appropriately as close as possible to the site of the operation.
|
|
|
|
|
We divide our whole application into layers , tiers, components etc. for modularity of a functionality. Cant we have a whole layer just to handle exceptions. In that case if we know that an exception is not being handled properly we will know where to go instead of having to browse through the whole code looking for the pertinent error.
|
|
|
|
|
Basically you either handle the exception, you ignore it (maybe with a message), or you log it (or combination). If you are logging, then basically you are centralizing the handling of the exceptions. What do you expect to do if you try to centralize the exception handling. That would be extremely complex. There are a number of frameworks for logging. We use log4net: log4net Tutorial[^]
|
|
|
|
|
Exceptions are part of the layers where they serve the best purpose, not a layer by itself.
|
|
|
|
|
Handle the exceptions you know you can handle as close as possible.
If you have a place no exceptions can be allowed to escape from, catch the root exception type - this will also catch all derived exceptions. But do this catch last, after the exception types you have different handling for.
If all your exception handling does is log an error, you only need to capture the root type.
|
|
|
|
|
You should know the .NET framework well enough to know what exceptions a method throws. For example, opening a file may cause an exception if the file doesn't exist, etc. Why would you have an application level exception handler for that? The method that opens the file should pop up a message box saying the file was not found.
|
|
|
|
|
On Error Resume Next
SMACK ouch, owe that smarts!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Phanindra261 wrote: When creating big applications(even medium apps) there are so many different kinds of exceptions that can come?
How to go about handling them?
Ideally by the following
1. Anticipate expected conditions that can result in errors. These of course vary by the area of the application/enterprise in which they appear.
2. Consider what the application/enterprise should do when those occur. This includes how or even if it should be logged.
3. Implement the code based on 1/2
4. Unit test the code of 3, including the exception generation
5. Besides the above boundary layers should ALWAYS assume that unexpected errors will occur. Those exceptions should be caught and logged once (not every layer.) Each layer must determine what the result is when an unexpected exception occurs and what the layer (or specific parts of the layer) do when an unexpected exception occurs.
As an example...
A database layer should always expect that communication errors will occur. There are various ways of dealing with this (which do not matter for this discussion) but they should still be expected. Even a clustered database solution can experience communication failure. Whether this is logged depends on how it is handled but even if the database layer is returning it as a result failure is should not log a stack trace, but just log it as a single error (db comm error.)
A database layer should not normally expect a SQL syntax error. That is something that should normally only occur during development or QA. So if it occurs one must log it. The database layer can handle this as a failed result.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
