»Make everything as simple as possible, but not simpler.»
Try Catch blocks are tricky bitches.
I've ranted about them before.
Do not abuse them. How do you abuse them you ask? You use them to catch only System.Exception, anywhere in your code without thought. And then do nothing with the exception. Why do nothing? Because you caught System.Exception which is completely fucking useless in determining what went wrong! There I said it. Sorry mom, this deserved an F-Bomb...
I found this article via DotNetKicks the other day. It describes some best practices in handling .NET exceptions. When I read the article it was a little annoying, but not quite enough to make me respond. But now after reading another DotNetKicks referral on try..catching(I'll hit that one later in this post), here it goes. There's a link to the MSDN best practices dealio on handling exceptions. Bravo. More people should read those docs, judging from code I've seen, very few .NET developers have seen the design guidlelines.(if you're reading this and you're one of those developers who hasn't been there, GO THERE NOW!).
My beef with the article is the suggestion of throwing an exception that contains all of the details of what an end user could possibly do, due to this new exception. Here's the meat to my beef(I couldn't resist). An exception should be used for exceptional sitiuations. These situations are ones that you as a programmer have no control over and cannot necessarily test for or predict, hence an exception would occur. If I can't connect to a database because the network went down, I'll get a SqlException with a message and other information indicating so. Without creating a "wrapper exception", some global exception handler in your application can catch that and determine "oh, there's a SqlException, indicating we can't see the database anymore, let's see, what can the user do....oh ya, NOTHING." And display any one of a million great error pages like these great 404 error pages highlighted on the bomb ass smashingmagazine.com site.
Don't get me wrong, the author lists 4 things for better exception handling, my prob is with #3, the others are spot on. There's no way as the developer of some classes that will be used by someone else, to know what the user's options are, since you won't know who the user's are to begin with. There's no course of action, nothing. Something broke, let it bubble as close to the user as possible but not all the way, at the last possible moment, intercept and handle appropriately, don't waste time binding volatile information like support details to custom exceptions in your code.
Albert Einstein
The title of this post is a quote from Albert Einstein. This post was actually inspired by this article on try-catching in a single line of code. I realize the code example was strictly just an example, but I can't help but be annoyed by the returning of values just as worthless as an HRESULT.(oh ya, don't miss the COM days at all!)
So back to the code. Taken for what it is, an extension method that can be used to catch exceptions, yay, cool example. However, if I ever saw that in someone's code I had to maintain I think I'd explode. It doesn't make sense. You're taking a step backwards with delivering error codes in place of the exceptions. That's crazy. Why wouldn't you want that exception to bubble up? I guess it might depend on the app, but c'mon, return codes in place of SEH(Structured Error Handling) that everyone whined about needing in the COM days?(and yes i realize you don't have to return an error code, but you're still doing "something" inside of a masked catch block that can be handled in a better place, closer to the application level).
Some Thoughts on Exception Handling(and Throwing)
One of the commenters(Will) of this article said it best ..."handle your exceptions at the last possible moment within the current context." For applications, that usually means the UI layer... and that is absolutely the truth.
My rule of thumb(more of a guideline not set in stone) on throwing exceptions is at the method level. If a method cannot succeed without proper inputs, an appropriate exception should be thrown indicating that fact. This forces the input checking all the way back to the end user if need be. If my code on the backend requires that the user typed in an integer for whatever, i'll be checking on the backend for an int and throwing an exception(either i or some piece of .NET will throw that exception) and the end user will be faced with a yellow screen of death. What does that mean? if the user must put an int into a field, then make sure whatever the UI is, winform, webapp, whatever, checks at that level to make sure the user entered that information appropriately. It's VERY easy to do. You just have to do it...