asked on Robust Exception Handling in Java
Hi. Basically I need some general advice about how to handle Exceptions in my Java program.
I'm a student and as a favour for a company I'm writing a program which is used to enter data to a database and transfer data back and forth between the database and some excel files (for printing graphs and such).
One specific question I have is, I have inner SwingWorker classes that handle the data transfers between the database and the excel files. Should I handle Exceptions within those classes or send them to the outer class for processing? If the latter, how can I do that with a SwingWorker class since I just call the execute method and this runs the doInBackground method, which as I understand can not throw exceptions?
The other, and main, question is how should I handle Exceptions in general? I do propagate them up but the issue is, lets say I have a method with couple of hundred lines. Should I have the whole code in a single try block and catch exceptions at the end? Or should I catch them more often so that I can pinpoint errors? Also what about RuntimeExceptions?
The issue is that the company is abroad. Once deployed I won't be around. I need to be able to fix the code here and send it to them, if that's even possible. And I don't want the program to crash under any circumstances, at least not without displaying a message before hand so right now I'm catching every throwable, just to display a message before closing and writing it to a log file.
I'm open to any suggestions...
I'm a student and as a favour for a company I'm writing a program which is used to enter data to a database and transfer data back and forth between the database and some excel files (for printing graphs and such).
One specific question I have is, I have inner SwingWorker classes that handle the data transfers between the database and the excel files. Should I handle Exceptions within those classes or send them to the outer class for processing? If the latter, how can I do that with a SwingWorker class since I just call the execute method and this runs the doInBackground method, which as I understand can not throw exceptions?
The other, and main, question is how should I handle Exceptions in general? I do propagate them up but the issue is, lets say I have a method with couple of hundred lines. Should I have the whole code in a single try block and catch exceptions at the end? Or should I catch them more often so that I can pinpoint errors? Also what about RuntimeExceptions?
The issue is that the company is abroad. Once deployed I won't be around. I need to be able to fix the code here and send it to them, if that's even possible. And I don't want the program to crash under any circumstances, at least not without displaying a message before hand so right now I'm catching every throwable, just to display a message before closing and writing it to a log file.
I'm open to any suggestions...
Java
Last Comment
Mick Barry
put a try/catch inside your doInBackground() method
ASKER
I do have that already. My question is should I handle it there, as in display a message and log the error or throw it back up so that it can be handled at the "highest level" possible. I get the idea that this is a good programming practice.
depends on the error, how serious it is, whether you can recover from it etc etc.
Its a business decision.
Its a business decision.
ASKER
But is it actually possible to throw it back up in a SwingWorker? Most of my exceptions would be about the database connectivity or the excel files, pretty much unrecoverable no matter where in the program. I just want to display messages, print a log and be able to pinpoint the error later on from the log.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
So I can throw exceptions from doInBackground and catch them through get()? Awesome..
What about catching exceptions often, so that I can pinpoint errors? And also RuntimeExceptions?
What about catching exceptions often, so that I can pinpoint errors? And also RuntimeExceptions?
you can catch throwable if you want.
It's quite an area of debate, but the exception handling should also be considered in conjunction with your logging strategy. Logging can be streamlined by delocalising so that fewer call to log exceptions are made. This is commonly done by catching checked exception and rethrowing unchecked ones. This is covered here, in 'Best Practices ...' which is very much worth reading:
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
ASKER
I have read this website before, besides several others and tried to stick to their suggestions.
My main problem stems from the fact that the program will be deployed abroad and I don't have the luxury of investigating the circumstances it failed. When it does fail I need to figure out everything I need from the log file which will be sent to me, fix the code and resend it to them. When errors occur, I need to be able to pinpoint them. This is the first time I'm dealing with exceptions, as in actually doing something in the catch block:) so I'm not experienced. If I use unchecked exceptions and not check them (that's the point of "unchecktedness" as I understand) it won't be in the log file. Also if I enclose a whole method within one try close, it'll be very difficult to pinpoint origins of exceptions, like NullPointerExceptions.
My main problem stems from the fact that the program will be deployed abroad and I don't have the luxury of investigating the circumstances it failed. When it does fail I need to figure out everything I need from the log file which will be sent to me, fix the code and resend it to them. When errors occur, I need to be able to pinpoint them. This is the first time I'm dealing with exceptions, as in actually doing something in the catch block:) so I'm not experienced. If I use unchecked exceptions and not check them (that's the point of "unchecktedness" as I understand) it won't be in the log file. Also if I enclose a whole method within one try close, it'll be very difficult to pinpoint origins of exceptions, like NullPointerExceptions.
You should be logging all exceptions, and as I mentioned earlier how to handle an exception is a business decision.
These days the majority of applications are deployed at a different site, we client apps running on various servers around the globe. Good logging helps us pinpoint the cause of any problems that occur.
> Also if I enclose a whole method within one try close, it'll be very difficult to pinpoint origins of exceptions, like NullPointerExceptions.
exceptions include a stack trace that tells you exactly where it was thrown.
These days the majority of applications are deployed at a different site, we client apps running on various servers around the globe. Good logging helps us pinpoint the cause of any problems that occur.
> Also if I enclose a whole method within one try close, it'll be very difficult to pinpoint origins of exceptions, like NullPointerExceptions.
exceptions include a stack trace that tells you exactly where it was thrown.
>>If I use unchecked exceptions and not check them ...
That's not the suggestion. The idea of rethrowing unchecked exeptions is not to avoid catching them. You should reread that article if you plan on doing any serious development
That's not the suggestion. The idea of rethrowing unchecked exeptions is not to avoid catching them. You should reread that article if you plan on doing any serious development
rethrowing them is very rarely a good idea.
And that articles a little dated
have a read here
http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html
And that articles a little dated
have a read here
http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html
ASKER
Can I tell which line the exception originated from using the stack trace?
Yes, the stack trace will tell you the line number if the source was compiled with debug info
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.