Quick Error Handling Question

[Novice]

I'm trying to learn more about Error Handling. I've read the Java Tutorial
topic on it, as well as Bloch's Effective Java (2nd edition) tips on it.
I've started on Robust Java by Stephen Stelting too. I know I'm going to
have more questions later but one is bugging me right now and I'm not
seeing it mentioned anywhere so let me ask now.

Should I write stacktraces from my checked and unchecked exceptions to my
log? Or just assume that all stacktraces will be written to the console and
the console will always be accessible to everyone who needs it?

 

[Arne Vajhøj]

I'm trying to learn more about Error Handling. I've read the Java Tutorial
topic on it, as well as Bloch's Effective Java (2nd edition) tips on it.
I've started on Robust Java by Stephen Stelting too. I know I'm going to
have more questions later but one is bugging me right now and I'm not
seeing it mentioned anywhere so let me ask now.

Should I write stacktraces from my checked and unchecked exceptions to my
log? Or just assume that all stacktraces will be written to the console and
the console will always be accessible to everyone who needs it?

In general I don't like multi line log messages, but stacktraces
are just too damn useful, so I would say log them anyway.

Arne

 

[Stefan Ram]

Should I write stacktraces from my checked and unchecked exceptions to my
log? Or just assume that all stacktraces will be written to the console and
the console will always be accessible to everyone who needs it?

When an exception is checked, it usually will be handled by code that
knows how to deal with it and, insofar, »has expected« it. So, often,
there is no need to log all details or to log anything at all.

What really needs to be visible with all details are unexpected
(i.e., not handled by specific code) runtime throwables.

When text can scroll out of a console, it is always possible that
it will not be observable.

 

[Arne Vajhøj]

[...]
Should I write stacktraces from my checked and unchecked exceptions to my
log? Or just assume that all stacktraces will be written to the console and
the console will always be accessible to everyone who needs it?

Only you can answer that question. No one here knows how your program is
going to be used, never mind whether such an assumption would be valid.

It's certainly not valid for _all_ Java programs. But who knows? Maybe
yours is special somehow.

I would put it exactly the opposite.

The OP does not know if the stack trace could be
useful one day out in the future.

And therefore he should log it.

Arne

 

[Arne Vajhøj]

Naturally. Of course you would.


Sorry. I wasn't aware that we had complete and precise knowledge of what
the OP does and does not know.

Actually - we know that he has not foreseen all potential problems
and therefore does know what information he could end up needing.

And even if it "could be useful one day out
in the future", if he already has the information from the console output,
the logging could be superfluous.

It is far better to have all info in one place instead of having
to try and correlate two sources of information.

Arne

 

[Arne Vajhøj]

When an exception is checked, it usually will be handled by code that
knows how to deal with it and, insofar, »has expected« it. So, often,
there is no need to log all details or to log anything at all.

I am a bit skeptical about the idea of checked exceptions being
dealt with and therefore no details being necessary.

You may catch a SQLException and be able to get the data right
in the database, but you may still want to know why it failed
in the first place. If it happens too frequently it may require
corrective action.

Arne

 

[Arne Vajhøj]

[...]

Sorry. I wasn't aware that we had complete and precise knowledge of what
the OP does and does not know.

Actually - we know that he has not foreseen all potential problems
and therefore does know what information he could end up needing.

You can't possibly know that for sure.

Oh - yes.

Nobody foresees all potential problems.

You haven't even seen the OP's
program, never mind know how complicated it is,

Well - if you had read and understood the original post and
the thread that it is following up on, then you would know
that it was a general question not for a specific program.

nor whether the OP has or
even could have foreseen all potential problems.

Nobody can. That includes OP.

But even if you could, you also don't know whether the stack trace remains
available via some other mechanism.

Let me copy paste what you chose not to quote:

#It is far better to have all info in one place instead of having
#to try and correlate two sources of information.

Otherwise, I suggest you brush up on your epistemology, as you seem to be
having trouble actually knowing what is truly _knowable_.

I don't disagree that logging stack traces is useful. But to claim that we
actually have enough information from the OP to answer the question with
100% infalliability is downright silly.

I think what is silly is to recommend coding practices
based on an assumption that one can foresee all problems.

Arne

 

[markspace]

Should I write stacktraces from my checked and unchecked exceptions to my
log?

I can't think of anyone who advocates logging literal stacktraces.
Usually, the log system will do something like that for you, so all you
have to do is call some method like:

log.severe( exception, "This is where I got the error." );

I'd not go too overboard with this. You can log too much. But do pay
attention to customer requirements. (Any customer, even internal ones.
I.e., your boss, the group that maintains your programs, etc.) If
they ask for more (or less), give it to them.

In general, I'd log exceptions where you catch them, and don't rethrow
or wrap and throw. If you throw a wrapped exception, someone else will
catch it and log it. If you catch an exception and don't rethrow
anything, you'll need to log it because at that point you're the only
one who knows it occurred.

Also, only log exceptions that actually unexpected or error conditions.
If a poorly written API forces you to catch an exception as part of
something that could be considered a normal return value, don't bother
logging it if it wouldn't be interesting to someone trying to diagnose a
problem.

 

[Arne Vajhøj]

[...]

Actually - we know that he has not foreseen all potential problems
and therefore does know what information he could end up needing.

You can't possibly know that for sure.

Oh - yes.

Oh - no.

Nobody foresees all potential problems.

There are plenty of examples of programs that are simple enough to foresee
all potential problems for which emitting a stack trace would be relevant.

Not in serious programming.

Yes,

So you admit that your question about whether I had "seen the OP's
program" was completely bogus?

and as a general question and contrary to your stipulation, there is
no "one size fits all" answer.

Sure there is.

Log exceptions.

One may need it someday and it cost very little.

[...]

But even if you could, you also don't know whether the stack trace remains
available via some other mechanism.

Let me copy paste what you chose not to quote:

#It is far better to have all info in one place instead of having
#to try and correlate two sources of information.

I chose not to quote it because I don't disagree with it and it wasn't
relevant to the point I made in my original reply. The OP makes clear that
his concern is not whether "all info is in one place", but whether the
stack trace would be available at all.

It is extremely relevant, because it is a reason to log exception
even if it gets outputted elsewhere.

What is silly is to recommend coding practices based on any assumption.
Without the facts, you cannot know that a particular coding practice is
important or not.

I think you should read up on the concept of "best practices".

I know. For you, even a basic "Hello World!" program needs unit tests,
stack-trace logging, exception handling, source control, ad infinitum.
Suffice to say, I don't agree.

Not very relevant here. The OP is asking about what he should do
when he logs and catches exception. Not whether he should log and
catch exceptions.

And besides I am not interested in hello world programs. And
it seems based on host questions that OP has also moved on
to real programs.

Arne

 

[Daniel Pitts]

I'm trying to learn more about Error Handling. I've read the Java Tutorial
topic on it, as well as Bloch's Effective Java (2nd edition) tips on it.
I've started on Robust Java by Stephen Stelting too. I know I'm going to
have more questions later but one is bugging me right now and I'm not
seeing it mentioned anywhere so let me ask now.

Should I write stacktraces from my checked and unchecked exceptions to my
log? Or just assume that all stacktraces will be written to the console and
the console will always be accessible to everyone who needs it?

In general, it depends

More often then not, you should *not* be sending them to the console,
but *should* be sending them to the log. Most logging frameworks I've
seen have two methods overrides for error(), Usually along the lines of
void error(Object message) and void error(Object message, Throwable
throwable). Use the latter. This allows the logger to properly log the
stacktrace. I wouldn't be surprised (though I haven't looked) if there
was a way to configure the logger (at runtime) to include or exclude
stack traces.

At my current company, I'm advocating an "always log stacktrace"
approach. As always in engineering, "Always" mean's "Unless you have a
damned good reason not to."

Of course, if your program can gracefully handle a specific exception,
then you should not log the stack trace. Some examples of this are
IOExceptions, InterruptedException. Almost always a RuntimeException or
Error should be fully logged, since it indicates a bug or VM issue
rather than an exceptional state.

 

[Roedy Green]

Should I write stacktraces from my checked and unchecked exceptions to my
log? Or just assume that all stacktraces will be written to the console and
the console will always be accessible to everyone who needs it?

A stacktrace helps you figure out what caused an unexpected out of the
blue problem. If it is just a missing file causing the trouble, the
stack track is probably superfluous.

 

[Lew]

In general I don't like multi line log messages, but stacktraces
are just too damn useful, so I would say log them anyway.

This is where you use log levels.

Log headlines at "error" level (SEVERE or ERROR depending on library). Think
about what's appropriate for stack traces case by case. I usually log the
trace at "debug" (FINE or DEBUG), but there isn't exactly a recipe. In case of
trouble, the installation can play with log levels to open the information
floodgates in relevant areas, then shut them off again after diagnostics.

There is a principle, elucidated for you the other day. Logs are for
troubleshooting. Make them useful for people when they're troubleshooting. Not
for you just when you're developing, not for prettiness, not for confusion.
Read your own log files and see what they tell you. Try them at different
levels. Write unit tests that crash your code and see what's logged.

Make them useful. Arne's suggestion is wise - when you need a stack trace and
it isn't there, what now? Conversely, when you don't need it and it's there,
what harm? (I say there is some - but how much?) If it's configurable in the
field and you can get traces or not at will, how about that?

 

[Novice]

I'm trying to learn more about Error Handling. I've read the Java
Tutorial topic on it, as well as Bloch's Effective Java (2nd edition)
tips on it. I've started on Robust Java by Stephen Stelting too. I
know I'm going to have more questions later but one is bugging me
right now and I'm not seeing it mentioned anywhere so let me ask now.

Should I write stacktraces from my checked and unchecked exceptions to
my log? Or just assume that all stacktraces will be written to the
console and the console will always be accessible to everyone who
needs it?

Thanks to all who replied to my question.

Some of you already know this but for the sake of those who don't, this
was essentially a followup to the lengthy "Aspect Questions?" thread from
last week which started out as a general question about AspectJ but then
mutated into a general discussion of logging (for the most part). We went
over a lot of conceptual stuff and I got a lot of misconceptions sorted
out. I'm trying to apply that new knowledge to my existing programs now
and found that I couldn't see anything in what I was reading about error
handling that said whether any attempt should be made to log stacktraces
or whether I could safely assume that putting them on the console would
be sufficient. This was very much intended to be a general "best
practices" kind of question but perhaps that wasn't as clear as it could
have been.

The main thing I've learned from your replies is that it is rarely wrong
to log something that may be available from another source, even if it is
redundant, and that it is probably NOT safe to assume that a console that
might contain stacktraces is always going to be accessible to those who
need it. I had anticipated the first from the other thread and suspected
the second. Your confirmations were very helpful.

Thanks again!

 

[Martin Gregorie]

I am a bit skeptical about the idea of checked exceptions being dealt
with and therefore no details being necessary.

You may catch a SQLException and be able to get the data right in the
database, but you may still want to know why it failed in the first
place. If it happens too frequently it may require corrective action.

IMO the SQL Exception is the one case where a single line is almost never
enough. I'd say its always necessary to work your way down the
SQLException chain outputing the contents of all of them and, depending
in the program's structure and logic, it is often a good idea to add the
query's text as well[1].

Assuming, of course, that you're using traditional SQL statements rather
than some JPA.

 

[Arved Sandstrom]

I am a bit skeptical about the idea of checked exceptions being dealt
with and therefore no details being necessary.

You may catch a SQLException and be able to get the data right in the
database, but you may still want to know why it failed in the first
place. If it happens too frequently it may require corrective action.

IMO the SQL Exception is the one case where a single line is almost never
enough. I'd say its always necessary to work your way down the
SQLException chain outputing the contents of all of them and, depending
in the program's structure and logic, it is often a good idea to add the
query's text as well[1].

Assuming, of course, that you're using traditional SQL statements rather
than some JPA.

Can't speak to other JPA implementations, but with EclipseLink logging
you get potentially a multitude of information. Query text and bind
parameters are already available at FINE, and there's still FINER and
FINEST.

JPA is also well provided with its own exception classes: there are ten
or so subclasses of javax.persistence.PersistenceException. If something
underneath at the JDBC level throws a java.sql.SQLException you'll see
that too.

AHS

 

[Martin Gregorie]

On 3/4/2012 8:26 PM, Stefan Ram wrote:
Should I write stacktraces from my checked and unchecked exceptions
to my log? Or just assume that all stacktraces will be written to
the console and the console will always be accessible to everyone
who needs it?

When an exception is checked, it usually will be handled by code
that knows how to deal with it and, insofar, »has expected« it.
So,
often,
there is no need to log all details or to log anything at all.

I am a bit skeptical about the idea of checked exceptions being dealt
with and therefore no details being necessary.

You may catch a SQLException and be able to get the data right in the
database, but you may still want to know why it failed in the first
place. If it happens too frequently it may require corrective action.

IMO the SQL Exception is the one case where a single line is almost
never enough. I'd say its always necessary to work your way down the
SQLException chain outputing the contents of all of them and, depending
in the program's structure and logic, it is often a good idea to add
the query's text as well[1].

Assuming, of course, that you're using traditional SQL statements
rather than some JPA.

Can't speak to other JPA implementations, but with EclipseLink logging
you get potentially a multitude of information. Query text and bind
parameters are already available at FINE, and there's still FINER and
FINEST.

JPA is also well provided with its own exception classes: there are ten
or so subclasses of javax.persistence.PersistenceException. If something
underneath at the JDBC level throws a java.sql.SQLException you'll see
that too.

Good to know. I was only excepting due to lack of experience with them.

 

[Arne Vajhøj]

[...]
So you admit that your question about whether I had "seen the OP's
program" was completely bogus?

No, of course not.

You wrote "seen the OP's program".

And you answered yes to that you had understood that it was a
general question.

Isn't it complete bogus to ask a thread participant if he has seen
OP's program if you know that it is a general question not related to
a specific program????

Arne

 

[Jukka Lahtinen]

On 3/4/2012 5:10 PM, Novice wrote:

I can't think of anyone who advocates logging literal
stacktraces. Usually, the log system will do something like that for you,

The stacktraces are valuable when the software is in development stage.
And also, IF something crashes in production, they are very useful.
An end user doesn't expect to see a stacktrace and shouldn't usually be
shown it, but logging it often gives good information.

Also, only log exceptions that actually unexpected or error conditions. If
a poorly written API forces you to catch an exception as part of something
that could be considered a normal return value, don't bother logging it if

Agreed. And those unexpected exceptions are where also the stacktrace may be
useful.