Byron Nevins wrote:
> I think that is a fantastically good/important idea. E.g. the more
> unlikely/unusual the error, the more critical the error message is and
> the more unlikely that it will ever get tested.
>
>
I handle this a different way in CORBA. The LogStrings file is
generated from
a description, and I also generate log wrapper methods that log exceptions
as well as log wrappers for logging without exceptions. That way the code
just makes a simple method call on the wrapper, and the wrapper handles
LogRecord construction with the appropriate I18N message, exception
chaining,
or anything else needed. A missing entry in the log description turns
into a
compile time error, rather than a failure to find a key in a LogStrings
file at
runtime.
However, it is certainly possible (and likely at this point) that log
wrapper
methods exist that never get called, and that cannot be detected without
doing something like bytecode analysis, assuming that you know all of the
classes that are clients of the generated log wrappers.
Currently the log wrapper description is in Scheme S-expressions for
easy processing
by a JScheme program. I'll probably convert this to Java annotations on an
interface at some point, and generalize the current CORBA-specific
scheme to handle
any sort of logging and exception handling.
Ken.