On 14 Sep 2009, at 08:43, Robert K. wrote:
I find it debatable whether this pattern does make sense: if the
calling code can handle the exception in a meaningful way, there is no
point in logging it, because that would attract suspicion where it is
not in order. I would say that logging is a form of handling, i.e. if
the calling code does not know what to do about it, it can still log
the error. If you log it in the source location then this could be
viewed as violating the principle of “let the calling code decide how
to handle the exception”.
Possibly, although there are cases where having subsystems log unusual
occurrences for later analysis can be useful and it’s also quite a
nice pattern for triggering fail-safe behaviours at the right level of
encapsulation when they are necessary. The caveat being that I very
rarely find myself writing production code where that’s necessary.
One more reason against this pattern: if this is done on multiple
levels you’ll get the exact same error multiple times in the log which
does not really help clear things up.
I wouldn’t recommend using it at multiple levels unless each triggered
different behaviour, or the triggered behaviour was clever enough to
filter and distil. That may or may not be compatible with good data
encapsulation depending on the problem domain.
I hope this all makes sense, but if not I’d be happy to discuss it
Please let’s keep it on list. We would miss your mellow home brew
Oh to see ourselves through the eyes of others…
Games With Brains
raise ArgumentError unless @reality.responds_to? :reason