Re: Best practice question: logging

Pito Salas:

> I want to sprinkle my code (Ruby, not Rails) liberally with
> logging calls so that when things go wrong I can see what happened.

[=E2=80=A6]

> - how do I minimize the overhead when logging is OFF?

I=E2=80=99m stadning before this very choice at the moment.

In my previous program, I used a home-brew Log class (which operated
only using class methods, so I just simply used one Log object =E2=80=93 the
class itself =E2=80=93 in all of my code: Log.write "debug info").

Still, I now think that I=E2=80=99ll use the Ruby standard Logger class, but
instead of calling it explicitely in all of my code (going through all
of my methods and adding logging stuff to them, which I find both looks
ugly and in many cases makes them much longer) I=E2=80=99ll use metaprogram=
ming
techniques to wrap method calls with logging lines *if and only if
the logging is on*. I=E2=80=99m thinking someting towards AOP, and I played
with Aquarium=C2=B9 a bit. I think this is a similar approach that Pascal
J. Bourguignon meant when mentioning the Tracer class.

This approach allows to have a single place in code that does all the
logging (and says which methods emit log output), keeps the methods
clean and to-the-point (without any logging stuff in them) and means
that with logging off there=E2=80=99s exactly no overhead (the logging code=
 is
simply not included at all).

=C2=B9 http://aquarium.rubyforge.org/

=E2=80=94 Shot
--=20
Triskadekaphobiacs are presumably upset that, although 13.untrust appears to
succeed and reinforce their beliefs, the state doesn=E2=80=99t stick; 13.un=
trusted?
subsequently returns false. Similarly, logicians and cynics alike
must, respectively, rejoice and despair that true.untrust.untrusted?
is perpetually false.                         [Run Paint Run Run, ruby-core]