Type checking function parameters

[Eleanor McHugh]

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.

Please let's keep it on list. We would miss your mellow home brew
comments.

Oh to see ourselves through the eyes of others...


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Nick Green]

I think you guys are fairly over my head in this discussion, but my 2
cents for the logging question: I always make my loggy function log
with a prefix indicating severity/type of log message, i.e. the usual
[INFO], [DEBUG], [ERROR], and maybe an occasional [TOOBVIOUSTOLOG] or
[OMGWEARESOTOTALLYSCREWED] for good measure. This lets you fairly
trivially cat/grep/redirect or whatever you method of choice is to get
only the log levels you care about when checking the log, and makes
turning logging off for given categories fairly easy (just a change to
the log function, or ideally have the log function know what
"environment" its running in). Anywho, dunno how this scales, I can get
away with it in C but maybe inefficiency would be a problem in a
multi-user app if you did this with ruby.

Our particular culinary message might deserve an [INFO], but more likely
would get stuck with the [DEBUG] so it could be turned off once I was
confident in my buttering logic.

P.S. upon further reading (I really don't know how I so thoroughly
missed begin/rescue/else/ensure/end magic in my initial round of ruby
tutorials!), I've found there are a few good ways to handle this
situation