I'm new to Resharper and I'm trying to understand why it seems to suggest:
catch (Exception) { }
for
catch { }
and
catch { }
for
catch (Exception) { }
I'm baffled.
views:
310answers:
4
A:
It's just giving you alternatives to consider, which may spark some insight into improving your code. Just ignore the suggestion if it doesn't make sense.
tvanfosson
2009-03-20 19:16:45
+4
A:
Basically it's offering you a way of switching between the two alternatives, rather than making a concrete recommendation of which is better.
You can change what's offered under ReSharper / Options / Code Inspection / Inspection Severity - find the relevant option and change the priority between none, hint, suggestion, warning or error.
Jon Skeet
2009-03-20 19:16:48
Downvoters: Please explain your downvotes, or they're essentially useless.
Jon Skeet
2009-03-20 20:12:45
A:
Because sometimes when tidying catch blocks you move to/from catch(Exception ex) to catch(Exception) to catch and vice versa, depending on whether you're trying to purely filter, log/wrap, or swallow the exception. (See me requesting the same feature for CodeRush without being aware it even existed in R#)
EDIT: The link was previously labelled "Empty catch is bad" hence very correct downvotes!
Ruben Bartelink
2009-03-20 19:16:50
While that maybe true, but according to the OP, Resharper is suggesting to use catch{} if you use catch{Exception}
Alan
2009-03-20 19:24:15
catch() { ... } is not "an Empty Catch", it is just alt syntax for "catch(Exception) { ...} " the code inside braces does not have to be empty.. .You can (should) put code inside the braces. If not, then it IS evil as you are swallowing generic Exception...
Charles Bretana
2009-03-20 19:29:20
Not if it's at the absolute top stackframe of a thread. Do you not think it's useful to log an exception before the whole process falls over, for example? (There's nothing to say that part of the ... isn't "throw;")
Jon Skeet
2009-03-20 20:14:01
Mea culpa - didnt actually follow the link I posted. In my mind it was article that explained the difference between catch{...} and catch (Exception) {...}. cant find anything remotely like the post I was dreaming about now - IIRC something changed from .NET 1.1 vs 2 in this area (SEH exceptions?).
Ruben Bartelink
2009-03-20 20:43:13
@Alan: the link to the devexpress page is me asking DX to add the same facility to CR (I was doing code tidying and wanted to remove the "(Exception)" bit as I wasnt doing anything other than rethrowing. I'd have thought that that would be salient enough to gaurd against downvotes!
Ruben Bartelink
2009-03-20 20:45:14
@Jon Skeet - if you catch an Exception, you execute all the finally blocks on the stack; is that a good idea when your process is potentially in a corrupted state? Might throw more exceptions - or wreck persistent data. Instead, enlist your logging code on the UnhandledException event in AppDomain.
Daniel Earwicker
2009-03-20 20:49:05
More details here: http://stackoverflow.com/questions/666645/would-you-ever-not-catch-an-exception-or-throw-an-exception-that-wont-be-caught/666775#666775
Daniel Earwicker
2009-03-20 20:52:25
@Charles Bretana: For some reason in my head I wasnt considering them to be equivalent (as covered in my edited version), and I thought the link was to an article covering the difference. Pretty sure I'm with you now tho'...
Ruben Bartelink
2009-03-20 20:53:10
@Earwicker: I *suspect* I would want to execute all the finally blocks, yes. I also suspect that would happen even if I didn't have a catch block. Just because the exception is unhandled doesn't mean the stack doesn't get unwound and finally blocks executed. A simple test appears to confirm this.
Jon Skeet
2009-03-20 22:00:04
@Jon Skeet - depends on the OS, amazingly. On XP, the finally blocks run under some circumstances, on Vista (and recent Servers) they don't, which is the corrected behaviour. Finally blocks executing in response to a bug condition may throw again, or corrupt state, defeating attempts to diagnose.
Daniel Earwicker
2009-03-20 22:45:35
You can address the situation on XP by enlisting with UnhandledException to customise how the bug is handled without triggering finally blocks. Post on the CLR team's blog that may be of interest: http://blogs.msdn.com/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx
Daniel Earwicker
2009-03-20 22:49:03
Which in turn prompted this question from me: http://stackoverflow.com/questions/602066/why-doesnt-c-have-support-for-first-pass-exception-filtering
Daniel Earwicker
2009-03-20 22:50:14
Hmm, I just tested it on Vista and it's broken there as well! Andrew Pardoe mentioned that wanted to change it. Anyway - you can customise what happens thanks to the UnhandledException event.
Daniel Earwicker
2009-03-20 23:01:35
"AppDomainUnhandledException is thrown after the first pass doesn’t find a handler. The finally blocks don’t run. On Windows 7 and forward... the OS will NOT unwind the stack for you so the finallies won’t run period. On earlier versions of Windows the OS was inconsistent..." - Andrew via email
Daniel Earwicker
2009-03-20 23:31:39
@Earwicker, IS all above only true for unhandled exceptions? I.e., if you handle an exception, say 2 steps up the stack, then the finallys between the exception and the handler DO run, right ?
Charles Bretana
2009-03-23 19:56:25
+3
A:
Resharper does have another message that is more of a recommendation: it advises you not to catch the Exception class.
Daniel Earwicker
2009-03-20 19:53:06