2005/9/2, Nick Faiz <nickfaiz@gmail.com>:
On 02/09/2005, at 3:38 AM, Niclas Hedhman wrote:

> On Friday 02 September 2005 00:35, Emmanuel Lecharny wrote:
>> As you can exhibit the method name and the line number with %C and
>> %L,
>> it increases the message correctness.
> Very true, and my idea is to have a small utility that does the
> "trick" that
> Log4J does, i.e. fill in the stack, grab the second top element for
> "where
> was this detected" and the next element for "where was that called
> from"...

Well, that would be really cool. I've had a similar interest also.

  I wrote a small app. which works with stacktraceelement arrays to
dynamically generate or look up prepared error codes (Oracle like
messages) - also to see if existing records of similar stack traces
existed. I've always thought that end users see too many stack-traces
and that applications don't really gain by throwing away exception
information. The basic goal was to convert long stack traces into
meaningful error codes, which could be included in documentation, and
also to not lose information concerning what exceptions had been
thrown by the application's runtime history.

Let me know if you do something in this regard.

This is really interesting.  It would be really nice if we can convert 'assert' keywords at class-loading time by manipulating bytecode into the two statements above (logging and throwing IAE).

what we call human nature is actually human habit