My general philosophy is to throw the most specific exception per layer. For example, if your SQL Server layer gets a connection timeout, that layer throws a "Connection Timeout" exception.
The data access layer then throws a "Cannot access data store" exception, passing on the original exception as well. The business layer throws a generic "Data access" exception (passing the previous exception, which passes the previous exception). The UI layer catches all of this, logs it appropriately, then displays a user-friendly message (e.g. "Unable to access your data due to a technical issue. Please try again. If this issue persists, please contact your systems support group" -- or some such nonsense). A couple of recommended caveats: 1. Make sure that the data is logged where/when appropriate. Too much logging is better than too little, when it comes to error resolution. 2. Differentiate between exceptions and errors. An exception is "something bad and unexpected", and is something that the user *cannot* fix on their own. An error is something that is eminently fixable by the user (by changing data, starting a stopped service, etc.). If you throw an exception because of an "error", make sure that you catch it as early as feasible, and pass back appropriate status to your UI, so that it may display an intelligent error message to the user. 3. For "exceptions" (you know, those bad and unexpected things), consider having a single generic end-user message (like the one above), that is displayed to the user. In general, after one of these exceptions, if you must end the program, try to save any unsaved data locally, so the user can recover. 4. Consider the use of the Microsoft Exceptions Application Block. This has been a godsend to us. 5. Write an untrapped exception handler that will capture any/all untrapped exceptions. Use it to display a prettier dialog box than the one provided by Microsoft .NET. 6. Consider writing a class that will collect system diagnostic information whenever an exception bubbles up to the client. Key items to capture: - Executing program - Free disk space - Free memory - Open network connections - Screenshot 7. If in a corporate environment, consider using remoting to remote any client-side exceptions to a central server. You may not capture all exceptions, but you'll be thankful for the ones you do. -Rob -----Original Message----- From: Daniel Wilson [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 8:18 AM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Handling Errors Hey everyone, My apps are tiered having multiple UI, Facade, Business Logic, Data = Access layers usually. How do you typically handle errors in each = layer? Do you have SqlServer like error messages propagate up to the UI = or facade layer? Or do you have plenty of bool methods in the = DataAccess Layer indicating success failure and have it trap data store = specific errors? Or finally, do you created custom errors that are = specific to the layer but generic enough as to abstract the other layers = away from that layer's implementation. For example, a "DataStore = Unavailable" error thrown in the data access layer regardless of whether = it is a Sql Server "unable to make connection error" or even a file = access error if you have a xml file for a datastore? Just curious and any advice would be appreciated, Daniel Wilson =================================== This list is hosted by DevelopMentor(r) http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
