Empty catches’ blocks
-
Everybody is probably gonna hate me for saying this but there are times when you don't want anything to happen when you catch an exception. I do it often. I put comments in the braces to explain why though. Please don't hunt me down. ;P Peace
There are 10 types of people in the world, those who understand binary and those who dont.
There might be some scenarios, e.g., retrying. But in that case I would try and narrow down the exception type to an "expected" exception. If you just catch Exception how do you know that you're not swallowing a bug?
Kevin
-
agreed. If you actually have to eat an exception, make your catch as narrow as possible to let any other exceptions flow up to error reporting systems. You can use string matching off the messagetext to narrow things down even if the base exception is being thrown instead of something more focused.
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
dan neely wrote:
If you actually have to eat an exception, make your catch as narrow as possible to let any other exceptions flow up to error reporting systems.
I agree Dan. I've been bitten by bugs swallowed by empty catch blocks that catch Exception. A real pain to debug.
Kevin
-
Hi! Several days ago I debugged one service in customer machine, and so there weren’t any symbols and debug information. But this is not a big problem. The most important problem was empty catch blocks in the application. For example, try { File.Move(source, dest); } catch {} //… Other code here. It was terrible, because this service changed information in the database. And one another service tried to remove file of information is correct in the database. I’ve spent a lot time with cordbg before I’ve found issue. It was problem with user’s permissions. Empty catches are really horror. Don’t use theirs.
Yeah, and try something like this:
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);try { int zero = 0; int one = 1; int exception = one / zero; } catch { throw new InvalidOperationException(); }}
Let's say the exception is done by a third part plugin, so you can't control it. Want you try to catch it in the Application.ThreadException event? Ok, try it! ;) Not all scenarios allow you to fill the catch block.
free .net reporting and gdi+ tools www.neodatatype.net