From: Nick Green Date: 2009-09-17T11:13:23+09:00 Subject: Re: Type checking function parameters 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:) Eleanor McHugh wrote: > On 14 Sep 2009, at 08:43, Robert Klemme 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 >>> further >>> off-list. >> >> 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 > ---- > raise ArgumentError unless @reality.responds_to? :reason -- Posted via http://www.ruby-forum.com/.