|
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.
|
|
|
|
|
Ooh - this is one of those issues where people come down on one side or the other. Some people seem to like silently consuming exceptions so that they don't actually have to do any *hard* coding to deal with the exceptions - they should be hunted down and tarred and feathered.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
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. 
Peace
There are 10 types of people in the world, those who understand binary and those who dont.
|
|
|
|
|
True, especially when .net throws exceptions willy nilly.
.net is a box of never ending treasures, every day I get find another gem.
|
|
|
|
|
If you have one of those, go hunting for an alternate approach that does not throw an exception.
In .NET 1.x, it appeared there was no way to convert a string to an integer without getting an exception if it failed. However, you could go via the Double type's TryParse method and then cast the Double to an int. Double cannot represent the whole range of a 64-bit integer so this approach isn't suitable for numbers this large.
Thankfully .NET 2.0 added a whole load of TryParse methods for the other basic types. (They do much the same work as the old Double.TryParse).
|
|
|
|
|
Oooohh! The "Damn the torpedoes!" approach to coding, huh? Funny, I just about never write an exception handler that didn't actually handle the exception.
If your logic depends on an exception happening, you haven't solved the logic problem properly.
|
|
|
|
|
|
Thankfully, there's no place to vote on it. THAT'S an article??! I've seen more information on a frickin' sticky note! 
|
|
|
|
|
Maybe we're missing something, maybe there's more information but the font-color is white. Try selecting everything. 
There are 10 types of people in the world, those who understand binary and those who dont.
|
|
|
|
|
Dave Kreskowiak wrote: I've seen more information on a frickin' sticky note!
|
|
|
|
|
I hate you.
Constantly "Saving the day" should be taken as a sign of organizational dysfunction rather than individual skill - Ryan Roberts[^]
|
|
|
|
|
Look, most of the time it is possible to do things without an exception being thrown but sometimes it is just too much work to prevent it.
Therefore catch (Exception){}
I mean why bother looking for alternative approaches when try-catching is so easy.
-- modified at 2:05 Tuesday 5th June, 2007
There are 10 types of people in the world, those who understand binary and those who dont.
|
|
|
|
|
smyers wrote: I mean why bother looking for alternative approaches when try-catching is so easy.
Because it's so damn hard to debug. If you're gonna eat the exception, at least put some logging code in catch block.
"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
|
|
|
|
|
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.  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
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
Doing anything willy-nilly tends to lead to problems.
All decisions require thought and review.
|
|
|
|
|
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
|
|
|
|
|
Nasty. I've run into problems with these when maintaining code.
Kevin
|
|
|
|
|
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.
|
|
|
|
|
I used to include this function in some classic VB apps:
Function RunningInDevEnv() as Boolean
On Error Resume Next
Debug.Print 1/0
RunningInDevEnv = (Err.Number <> 0)
End Function
I was curious and tried running this in VB.NET:
Function RunningInDevEnv() As Boolean
On Error Resume Next
Debug.Print(1 / 0)
Return (Err.Number <> 0)
End Function
It compiles in VB.NET but always returns True.
I noticed the C# compiler does not accept 1 / 0 at all. Is the VB.NET compiler being so forgiving here a good thing?
Sad to say some poor soul as I write this is probably trying to port one of my old VB apps to VB.NET and wondering why some "weird" behavior by the classic app in development mode is not carrying over to VB.NET. I hope the gods above will forgive me.
I think the lesson is to try to avoid clever tricks like this, even when they work (for awhile).
|
|
|
|
|
Follow the white rabbit...
VB6 wouldn't compile Debug.Print statements into the final code, and therefore wouldn't compile in the expression being evaluated either. Therefore if you were in the environment the division by zero would cause an error to be raised but you'd resume at the next statement, and the error number would be set to something other than 0, but in the compiled code the line causing the error wouldn't be present, so the problem wouldn't occur.
A debug build of the VB.NET code would cause the error to occur and the operation would return True. A release build should not. See the documentation for ConditionalAttribute.
The C# compiler tends to have better diagnostics and won't allow you to compile division by a literal zero. You'd have to use a variable containing the value 0.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
