tag:blogger.com,1999:blog-5822946.post112690033559671131..comments2014-09-17T10:15:34.033-05:00Comments on Marc's Musings: Exception handling in .Net (some general guidelines)IDisposablehttp://www.blogger.com/profile/02275315449689041289noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-5822946.post-18057105428549071252007-06-07T17:53:00.000-05:002007-06-07T17:53:00.000-05:00issoft:Logging an exception is NOT handling it. T...issoft:<BR/><BR/>Logging an exception is NOT handling it. That's just noting that you had a problem for later diagnosis and does NOTHING to insure that your code can continue or recover.<BR/><BR/>Handling an exception is something like trying to open a read-only file, which throws an exception that you catch, realize that the file is read-only, change it's attributes and retry.<BR/><BR/>With your strategy of bubbling up a return code indicating success, nothing FORCES a coder to properly check and react that that failure, so they sometimes won't.<BR/><BR/>Let's say that you want to read a file's contents and emit to some service. Once the file is fully processed, you want to move it to a archive directory. During the processing of the file, something throws an exception.<BR/><BR/>With your return code strategy, if the caller of the "process the file" forgot to check the return code, they would move the file into the archive directory EVEN though it wasn't fully processed.<BR/><BR/>With an exception-based strategy, you would fast-fail all the way out of the entire process the file and move the file to a top level handler (where it's logged and possibly moved to a bad directory) without the smallest chance that someone ignored the failure.IDisposablehttps://www.blogger.com/profile/02275315449689041289noreply@blogger.comtag:blogger.com,1999:blog-5822946.post-4271201389185030102007-06-07T15:07:00.000-05:002007-06-07T15:07:00.000-05:00As I see the matter the rule #1 never applies as y...As I see the matter the rule #1 never applies as you ALWAYS know what to do when you have an unknow exception:<BR/><BR/>- Catch it, log it, explain to the user that something wrong has happened and most times end your application (usually you don't know the current state of it) or if the exception concerts only a subsystem of the application stop that subsistem.<BR/><BR/>As with this approach you handle everything rule C changes to "always log at the lowest level". To signal the exception all the methods returns always a boolean with true if the method ended ok or false if it don't.<BR/><BR/>This approach works wonders for me. Just a example:<BR/><BR/>You have a batch processing of x files, if one throws an exception somewhere, the exception gets logged, the false value returned goes up thru the chain of calls and that file gets marked as faulty.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5822946.post-75454048505847988332007-04-24T03:02:00.000-05:002007-04-24T03:02:00.000-05:00This is the best post about exception handling i h...This is the best post about exception handling i have seen so far.Sakthihttps://www.blogger.com/profile/13894629780054143558noreply@blogger.comtag:blogger.com,1999:blog-5822946.post-1011282255982450632007-04-23T13:55:00.000-05:002007-04-23T13:55:00.000-05:00Bill:It depends, are you going to add value by doi...Bill:<BR/><BR/>It depends, are you going to add value by doing this translation, and this hiding the nature of the real exception?<BR/><BR/>Your example is the classic question about whether the DAL should let provider-specific exceptions leak out. To make a reasonable decision, ask yourself if you would react or catch the exception differently. Would you even catch (other than to log) any of these exceptions and how would you deal with them?<BR/><BR/>Perhaps you are writing a ASP.Net application, in which case you need to generally log the errors and direct to a general error page. In that case wrapping the exception in another gains you nothing.<BR/><BR/>If, on the other hand, you are writing web service and you <B>want</B> to obscure the actual database-specific detail when shuffling it out to the caller... in that case you would either wrap low, like you are suggesting, or catch high and issue a generic exception for the WSDL wrapper to pass through. Personally, I would opt for the latter as I can then <B>verify</B> at my interface methods that I'm always obscuring the details.<BR/><BR/>So, long and short of it... if you have a defined interface for the DAL that is <B>specified</B> to obscure the details, then you should do so as you are treating that as an black-box service boundary. In that case, the inner exception should <B>NOT</B> be set, and it should be logged withing the DAL as needed. This means that you need a cross-cutting concern to catch all exceptions at the service boundary and translate ALL of them... something that should probably be done with an aspect injection system (and thus, once again not code YOU should be writing).IDisposablehttps://www.blogger.com/profile/02275315449689041289noreply@blogger.comtag:blogger.com,1999:blog-5822946.post-11469681827300779112007-04-23T13:25:00.000-05:002007-04-23T13:25:00.000-05:00Regarding #2 above. Wouldn't you want to translat...Regarding #2 above. Wouldn't you want to translate from one exception type to another to reduce coupling? For example, would you want your data access layer to allow a SQLException out to the business layer, or would you want it catch and throw a DAL-defined exception?Bill Arnettehttps://www.blogger.com/profile/12950174681799205729noreply@blogger.comtag:blogger.com,1999:blog-5822946.post-72197478503772579262007-04-23T12:06:00.000-05:002007-04-23T12:06:00.000-05:00Neil:Excellent point. Updating.Neil:<BR/><BR/>Excellent point. Updating.IDisposablehttps://www.blogger.com/profile/02275315449689041289noreply@blogger.comtag:blogger.com,1999:blog-5822946.post-48522110667755312892007-04-23T11:14:00.000-05:002007-04-23T11:14:00.000-05:00Last submitted comment should be System.Reflection...Last submitted comment should be <BR/><B>System.Reflection.MethodBase.GetCurrentMethod().Name</B> not System.Reflection.MethodBase.GetCurrentMethod().FullNameAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5822946.post-61642028552088608222007-04-23T11:10:00.000-05:002007-04-23T11:10:00.000-05:00Enjoyed your article - full of useful tips.Reached...Enjoyed your article - full of useful tips.<BR/><BR/>Reached it from a post (by you I assume) at: http://codebetter.com/blogs/karlseguin/archive/2006/04/05/142355.aspx?CommentPosted=true#commentmessage<BR/><BR/>Can I suggest, as an ammedment to 6.<BR/><BR/>ex.Data.Add(String.Format("{0}.{1}.SQL", System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName, System.Reflection.MethodBase.GetCurrentMethod().FullName),command.Text);<BR/><BR/>This will work in static methods where the 'this' keyword is unavailable and will also provide the method name dynamically.<BR/><BR/>I'd be interested to know if you felt this had drawbacks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5822946.post-1135115088981986702005-12-20T15:44:00.000-06:002005-12-20T15:44:00.000-06:00Note that the Exception.Data is a framework 2.0 fe...Note that the Exception.Data is a framework 2.0 feature.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5822946.post-1126948082677824552005-09-17T04:08:00.000-05:002005-09-17T04:08:00.000-05:00Excellent post. Exception handling in my developme...Excellent post. Exception handling in my development has always been a crux. I'm gonna follow your guidelines, it's the best I've seen so far.Anonymousnoreply@blogger.com