Our code catches the general exception everywhere.
Usually it writes the error to a log table in the database and shows a MessageBox to the user to say that the operation requested failed. If there is database interaction, the transaction is rolled back.
I have introduced a business logic layer and a data access layer to unravel some of the logic. In the data access layer, I have chosen not to catch anything and I also throw ArgumentNullExceptions and ArgumentOutOfRangeExceptions so that the message passed up the stack does not come straight from the database.
In the business logic layer I put a try catch. In the catch I rollback the transaction, do
the logging and rethrow.
In the presentation layer there is another try catch that displays a MessageBox.
I am now thinking about catching a DataException and an ArgumentException instead of an Exception where I know the code only accesses a database.
Where the code accesses a web service, then I thought I would create my own “WebServiceException”, which would be created in the data access layer whenever an HttpException, WebException or SoapException is thrown.
So now, generally I will be catching 2 or 3 exceptions where currently I catch just the general Exception, and I think that seems OK to me. Does anyone wrap exceptions up again to carry the message up to the presentation layer?
I think I should probably add a try catch to Main() that catches Exception, attempts to log it, displays an “Application has encountered an error” message and exits the application.
So, my question is, does anyone see any holes in my plan? Are there any obvious exceptions that I should be catching or do these ones pretty much cover it (other than file access – I think there is only 1 place where we read-write to a config file).
I would use try/finally (or the using statement which is equivalent) for your rollback, rather than doing it in a catch block. In particular if you are only catching specific exceptions, you will still want the database rollback to take place if an unexpected Exception type is thrown.
With few exceptions I rarely use a catch anywhere except:
At a physical tier boundary I use try/catch with log/throw in the catch block so that exceptions can be logged on the server. With newer technologies such as WCF exceptions can be logged without a try/catch (e.g. with a WCF DispatchBehavior).
In a top-level handler in the presentation tier.
In the business and data tiers, there will be a lot of try/finally (i.e. using statements) but almost never a catch.