64 lines
3.0 KiB
Plaintext
64 lines
3.0 KiB
Plaintext
=== is related to: S5754
|
|
|
|
=== relates to: S2221
|
|
|
|
=== on 20 Mar 2015, 12:17:52 Tamas Vajk wrote:
|
|
I'm not sure about this rule. It will generate a lot of issues. Why is it better to handle two exception types than just the generic ``++Exception++``?
|
|
|
|
|
|
For example in the example we handle three exception types, but that doesn't cover all the possibilities: \https://msdn.microsoft.com/en-us/library/ms143369(v=vs.110).aspx
|
|
|
|
|
|
So we would only force the user to add one more exception type, and that would suppress the warning. But this won't mean that he doesn't have a catch clause that is too generic.
|
|
|
|
=== on 20 Mar 2015, 16:17:48 Ann Campbell wrote:
|
|
\[~tamas.vajk] we have a different rule for catching ``++Exception++`` but perhaps this rule and that one are indeed redundant(...?)
|
|
|
|
|
|
Generally, the thinking is that if you catch too high up the chain (e.g. Exception) then you are likely to mis-handle the more serious exceptions if all you're really expecting (and write code to handle) is something relatively minor & you should let the big things bubble up.
|
|
|
|
|
|
Specifically for your example, I'd say that catching ArgumentNullException is bad design: should have handled a null arg before the File call was made. Which just leaves UnauthorizedAccessException (which seems reasonable) and Exception (elephant gun).
|
|
|
|
|
|
Or perhaps this is a language-based difference in perspective? (.NET vs Java?)
|
|
|
|
=== on 23 Mar 2015, 07:26:05 Tamas Vajk wrote:
|
|
\[~ann.campbell.2], you are right, the null arguments should be checked before with an ``++if++``, which is way more performant than the ``++try-catch++``.
|
|
|
|
=== on 23 Mar 2015, 11:38:50 Ann Campbell wrote:
|
|
\[~tamas.vajk] I've updated the compliant solution. My assumption is that we only want to catch what's reasonable to expect in the method & let everything else bubble up. S'okay?
|
|
|
|
=== on 23 Mar 2015, 12:17:56 Tamas Vajk wrote:
|
|
\[~ann.campbell.2] makes sense. But if we want our application to fail gracefully, we will still need to provide a generic ``++Exception++`` handler on top level, and that will always trigger this rule. In the meantime, I could find one valid use-case for generic ``++Exception++`` handlers:
|
|
|
|
|
|
----
|
|
try {
|
|
DoSomething();
|
|
}
|
|
catch (Exception exc) {
|
|
logger.Log(exc);
|
|
throw exc;
|
|
}
|
|
----
|
|
So this should be an exception from this rule.
|
|
|
|
|
|
|
|
=== on 23 Mar 2015, 14:37:05 Ann Campbell wrote:
|
|
I'm not so sure about that [~tamas.vajk]. Here's why: RSPEC-2139 - Exceptions should be either logged or rethrown but not both. Do you have another permutation of this exception?
|
|
|
|
|
|
And/or do you feel strongly about this? In which case, I'll add the exception.
|
|
|
|
=== on 23 Mar 2015, 15:19:55 Tamas Vajk wrote:
|
|
\[~ann.campbell.2], I see, this makes sense. I'll try to think about this a bit more, but for now it seems I can't challenge this rule any further :-) It seems to be okay.
|
|
|
|
=== on 20 Apr 2015, 08:21:00 Ann Campbell wrote:
|
|
\[~evgeny.mandrikov] why move the code samples into a subtask?
|
|
|
|
=== on 20 Apr 2015, 08:32:50 Evgeny Mandrikov wrote:
|
|
\[~ann.campbell.2] because existing one was C#-specific.
|
|
|