Since I started to work on the server almost 6 years ago, I was
convinced that writing StackTraces in the logs was a error, as it could
fill the logs very quickly, and make them grow so fast that any valuable
message could be buried into millions of lines of stack trace.
If errors are swallowed or converted into other Exceptions it's always
not easy to trigger the real error cause. That's why I get used to log
an error when catching it - even when throwing afterwards a transformed
error.
What about having a dedicated log file only for errors? Like this the
common log file would still be readable.
Right now, I think that I would rather have those stackTraces instead of
spending hours debugging the server or adding some temporary
e.printStackTraces in some random places. Typically, today, I tracked
down a NPE which was generated by a error message using a null reference
to inform the client about the cause of the error. Isn't it ironical
that trying to give back some info when some error occurred you get a
NPE ? No. In fact, it happens all the time, but we aren't protected
against such mistakes.
Now, I would suggest we add some handling of such exception at the
higher level, ie in core-session.
+1
Overall it would be helpfull if we can still get the causing error and
it's location even when mapping and/or swallowing errors for various
reasons. Java5 can be helpfull as Exception can more and more be used in
a cascading way.
