Logging every error

[Steve Wood]

Hi guys,

A quick question - hopefully with a quick and simple answer.

How do I get Java to log every error our software makes. I mean everything - so we can get the log file. I don't care if it's got other software in the log, but we need to get errors back.

The software is a swing application.

Thanks in advance,

Steve

[Peter Chase]

There is probably no quick and easy solution.

First, you have to specify what you mean by "error". There is a class java.lang.Error, which gets thrown in extreme problem situations. Most java.lang.Error indicate irrecoverable situations (e.g. out of memory), in which your program should generally terminate.

If by "error" you actually mean "exception", then you have a different problem. There are lots of exceptions which are thrown, but do not necessarily represent an "error", just an unusual situation. The program might be dealing with such exceptions frequently.

Anyway, there is no way in Java to catch and log all exceptions that are thrown.

Well, there isn't unless you can run your program in a debugger. Most Java debuggers can be configured to break into the program every time an exception is thrown.

[Steve Wood]

Thanks Peter,

I had a feeling it wasn't going to be easy. Essentially, I want to catch all unusual conditions, errors, and exceptions. I don't really care how critical they are - I just want to know if they happen.

Eclipse seems to pull this off - if in debugging mode, it can isolate the code and take you to the exact line. I'm not building a development tool though!

I saw this in the Java Developers Almanac, but I don't really get it:

"All errors and exceptions extend from Throwable. By catching Throwable, it is possible to handle all unexpected conditions.

There are several scenarios where it is good practice to catch Throwable. For example, in a server application, the threads that handle requests should catch Throwable and relay any errors or exceptions to the client. Another scenario is a long-running thread that performs some background activity. Such threads should catch Throwable, log any errors or exceptions, and then continue functioning.

It is rarely good practice for a method in a library to catch Throwable. In general, errors and exceptions should not be masked from the caller.

This example demonstrates a long-running thread that catches Throwable and logs the exception."

class BgThread extends Thread {
// Create a logger. For more information on the logging api's,
// see e385 The Quintessential Logging Program
Logger logger = Logger.getLogger("com.mycompany.mypackage");

BgThread() {
// As a daemon thread, this thread won't prevent the application from exiting
setDaemon(true);
}

// Set to true to shut down this thread
boolean stop = false;

public void run() {
while (!stop) {
try {
// Perform work here
} catch (Throwable t) {
// Log the exception and continue
logger.log(Level.SEVERE, "Unexception exception", t);
}
}
}
}

[Peter Chase]

Eclipse is a debugger, among many other things. It can do things that your Java program cannot.

You can add code to catch Throwable. As you say, it is not something to do often. More importantly, though, it will not catch Errors/Exceptions that have already been caught. And I'm guessing that your program's code is already catching most of the Errors/Exceptions, because were it not, it would crash.

[Stan James]

If you're really bold, you could look into byte code modification. I saw a pitch for a tool that modifies Exception as it is loaded so it can track every exception created via extra code in the constructor.

[Jan Groth]

hello,

Anyway, there is no way in Java to catch and log all exceptions that are thrown.

hm, not true in all cases. aop makes it possible ;-)

i'm using spring as lightweight application framework. should i want to catch all exceptions, i could define an aspect which is executed whenever a method throws an exception... not very performant, but definitely an option.

i'm not really getting how high everything is put here in this post. obviously you are logging everything of importance with a logging framework. whatever "everything of importance" means :-)

so - stupid sounding question - where is the problem?

- you expect errors which are not logged? not good. write more logging statements.
- or are you talking about non-exceptional errors ("userlist should not be empty"). obviously this kind of error is not auto-detectable. write more logging statements.
- you are satisfied with your logging, but want extra notification? if so, i would not understand this requirement. for what benefit?

maybe you can clarify a bit more,

best regards,
jan

[Peter Chase]

Originally posted by Jan Groth:
not true in all cases. aop makes it possible

What's "aop"?

[Jan Groth]

serious question?

aspect orientated programming. weave central aspects (here: "logging of exceptions") with source-code points (here "method invocation").

can be done either at compile time through bytecode injection (AspectJ et al), or at runtime through dynamic proxies (Spring et al).

many greetings,
jan

[Steve Wood]

Hi Jan,

I'm thinking of errors where we just didn't expect the state of a particular GUI thing to happen. For example, we've had funny errors, where if someone forgets to put a number in one area, it causes an error in another area of the app. Not a big error, or anything that causes the application to run badly, just an error that we'd like to know about so we can fix it.

We log all big errors, like database things, file operations, etc, but not these niggly, GUI errors that are not major, but we'd like to improve upon.

I realise the answer can be "DO MORE TESTING!!!", but we can't catch everything (we don't have enough people). Ideally we'd like to have the app send back error logs every month so we can tweak the GUI accordingly.

Thanks for the help,

Steve

[Jan Groth]

hi steve,

okay, obviously you cannot auto-detect "funny errors" somewhere.

all you can do is try to think ahead, GUI fields can be empty, users can enter weired data, buttons can be clicked many times... try to log this as good as possible / required.

use a logging-framework like log4j and configure a rolling-file-appender. this will write logsfiles up to a certain size, starting a new file when the limit is reached.

you can further determine which level of errors will be logged whereto (each logging-statement gets its error-level when it's written). if you had one file-appender which only logs serious errors, and another one which logs everything, you can have a quick glimps at the error-log, and then investigate deeper in the info log.

obviously you need access to those file, either directly with ssh / ftp / ..., or someone has to mail it to you whenever necessary.

is this the direction you are investigating towards?

many greetings,
jan

[Jan Groth]

hi steve,

just re-read the thread again. i might be wrong, but can it be that the concept of "logging" is unfamiliar to you? this would explain some confusions we are having in understanding your needs.

you find a short summary here and also there, even though it might not be the easiest start if you are completly unfamilar with it, it's a good resource. and the log4j-logging-framework is quasi-standard for all business applications.

jan

[Jeroen T Wenting]

Of course it's impossible to log ALL possible errors. For example you can not log an error produced by the failure of the logging system itself, as the logging system would be unavailable to log it...

log4j or the J2SE logging API can be used to do the rest.

If you're trying to log an application without modifying its source, tough luck. You can do little more than redirecting the console output it may produce to a file and hope.

[Steve Wood]

Thanks Jan,

No, I'm not all that familiar with logging - except conceptually. I'll have a look at the articles. I haven't really used Log4J, but I'm aware of it. It's just that whenever I see error handling/logging examples, it's always in the context of things that actually throw errors.

We do do a lot of testing and wrap as much as we can around gui functions (in terms of validation, etc), but errors still creep in and we'd like to keep track of them.

I'm not sure how to be clear on this except to say: we basically want to get the stack traces you see when you're testing your app in an IDE.

However, we don't really want to put try...catch blocks in every single method we have.

Thanks for all the help - I've certainly got a lot to go on!

Cheers,

Steve

[Tony Morris]

If it's a swing application, then your exceptions are likely to be on the event dispatch thread. Simply attach an ExceptionListener to that thread.

I used to work a seriously broken swing application that proved difficult in ever knowing what any problem was ever - until I resigned a few weeks ago. You don't happen to work for a large corporation do you?