Empty catches’ blocks
-
dnh wrote:
Because it's so damn hard to debug.
No ways, when I have a bug that I can't find I just copy and paste MessageBox.Show(ex.ToString()); into all my empty catches(normally only two or three). Then I comment them out afterwards...sorted :)
There are 10 types of people in the world, those who understand binary and those who dont.
Then someone start using your code, and spend whole day finiding empty catch buried under tons of code. :sigh: Been there, cursed a lot. :)
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
-
Then someone start using your code, and spend whole day finiding empty catch buried under tons of code. :sigh: Been there, cursed a lot. :)
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
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
-
dnh wrote:
Because it's so damn hard to debug.
No ways, when I have a bug that I can't find I just copy and paste MessageBox.Show(ex.ToString()); into all my empty catches(normally only two or three). Then I comment them out afterwards...sorted :)
There are 10 types of people in the world, those who understand binary and those who dont.
Then put the
MessageBox.Show(ex.ToString());inside conditional code (does VB not have that?).catch ( System.Exception ex )
{if DEBUG
MessageBox.Show(ex.ToString());endif
}
-
Then put the
MessageBox.Show(ex.ToString());inside conditional code (does VB not have that?).catch ( System.Exception ex )
{if DEBUG
MessageBox.Show(ex.ToString());endif
}
Yes, it does. The problem is that just eating exceptions willy-nilly is horrifyingly bad practice. It makes someone comming up behind you to maintain your code want to hunt you down and kill you!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Yes, it does. The problem is that just eating exceptions willy-nilly is horrifyingly bad practice. It makes someone comming up behind you to maintain your code want to hunt you down and kill you!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Doing anything willy-nilly tends to lead to problems. All decisions require thought and review.
-
Thankfully, there's no place to vote on it. THAT'S an article??! I've seen more information on a frickin' sticky note! :laugh:
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Dave Kreskowiak wrote:
I've seen more information on a frickin' sticky note!
:laugh::laugh::laugh:
-
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.
Nasty. I've run into problems with these when maintaining code.
Kevin
-
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