=== 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.

