- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Stop Poking Me!
- Operation Erred Successfully
- A Dark Turn
- Nothing Doing
- Home By Another Way
- Coast Star
- Forsooth
- Epic
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Human milk is really good for you... Lots of valuable nutrients :)
That's pretty strange!
Admin
That's risky because who knows what side-effects the assignment might have. More commonly I see "(void) e;" which will be optimized away.
There's also a macro for just this purpose:
UNREFERENCED_PARAMETER(e);
Admin
Awwww. Come on... That just makes is exceptionally clear that e=e. It's spelled out for you.
Admin
... and another thing, this way no error could occur. What a great strategy to point out to management! Look my programs never produce errors!
Admin
Could be left in the code for when the developer was stepping through the code. Without a statement in the catch block, I don't think there's a way to look at the exception in the debugger.
Admin
I agree, very handy piece of code for debugging.
Admin
It's only handy for debugging if you're using VS 2002 or if you don't know about $exception.
Admin
if you are concerned about debugging, use System.Diagnostics code that you can keep in your code for Traces, etc. -- or use #if DEBUG or other compiler options...
Admin
I could only think of three reasons why she would have done this:
1. She didn't know you could have a general catch clause. I'm certain it's this one.
2. She wanted to do something with the caught exception but never got around to it. I could be convinced.
3. She wanted to have access to the caught exception in the debugger. You'll have a hard time convincing me.
It wasn't cruft left over from debugging. It was consistent, it was everywhere, and it was usually the only exception handling. If there was an exception, she wouldn't close the file she was writing to, close the database connection she was reading from, etc. She'd just set e to e and move on. WTF.
Admin
This could be valid code. If the try/catch block is placed in a loop, this could be an exception that amounts to "terminate the loop for this set of data, but continue the loop with the next sets of data."
A generic catch statement would catch all exceptions, even those that should signal loop termination. Alternatively try/catch blocks around every statement that could potentially throw is not very efficient to code or read.
IMHO, this is not poor code at all but a valid technique. I did not write this code, nor do I know the person who did :)
Admin
I still think it's for debugging. Even in VS2003, the $exception variable only shows up in the Locals window. Now, this usually isn't a problem unless you want to look at the stack trace. I tend to use immediate mode to look at stack traces, since the resultant strings are often too long to fully inspect in the Locals view.
However, even though there might be a legitimate reason for this idiom during early phases of the development process, I don't think there's any reason why such things should be hanging around a production-ready codebase.
Admin
I sometimes use
catch ( Exception )
{
.....
if ( .... ) throw;
}
Admin
Let me guess what those }’s close…
bool contains(...)
{
try
{
foreach (i in collection)
{
if (predicate(i))
{
return true;
}
}
}
catch (Exception)
{
// do nothing and pretend we haven't found it
}
return false;
}
Admin
Given that this was all over the place, my guess is that it is just a bad programmer using poor exception handling to hide bugs in the code.
Doing stuff like that is no better than ignoring return values. Although valid in some instances, it is more often just a sign of a programmer that doesn't know what they are doing.
Admin
I probably can assume why he does that. Because if you don't put anything in the catch block, the VS will always give a warning that the "e" is not used anywhere. If you delete the (Exception e) and later on you want to do something with it you have to write it again. Nevertheless the way he did it is quite abnoxious :-) :-)
Admin
If you want to catch a specific type, but don't actually want to do anything with the exception object, you can omit the identifier, e.g.
try
{
}
catch ( Exception /* no e */ )
{
}
Admin
Maybe the developer was testing the code optimizer to see whether tautologies result in no-op IL?
Admin
Hey, I used to do something like this
int i=0;
it was only so I had a line to place a breakpoint onto so I could look at the exception in debugging mode. Its not so dumb as it looks if you debug like that.
Now I tend to trace.write the exception instead, so that I can still debug attached or not
Admin
I always thought that was amusing/irritating that Exception e never actually existed in the catch if you didn't use it.
Admin
I actually had that SAME piece of code in something I wrote. The reason being if you catch an exception but don't do use it in there (remove the e=e), then you get warnings from the compiler that says you declared the variable e, but never used it...
e=e removes the warning... :P
Admin
Of course, you could also do
Try {...}
Catch { /Nothing/ }
just don't have (exception e)
Admin
<font style="BACKGROUND-COLOR: #efefef">Thats great... I often have empty catch blocks to supress exceptions, but when I need to inspect I usually have catch(e) { int i = 0; }. Still get the compiler whinging about unused variables. e=e is the perfect solution for exception blocks that will be filled in later or left blank, and you need a line to break on. (Sorry for the necrothreadphilia btw).</font>
Admin
Don't you all get it?
That is just letting Bygones be Bygones!