It's not a secret anymore!
The moose likes Beginning Java and the fly likes Can we catch Errors... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Can we catch Errors..." Watch "Can we catch Errors..." New topic

Can we catch Errors...

Chandra Bairi
Ranch Hand

Joined: Sep 12, 2003
Posts: 152
hello friends,
normally when an exception occurs they can be caught and handled.
But can errors be caught in similar way. How do we deal with errors if they are not caught and what is the best way to deal with them??

Igor Ko
Ranch Hand

Joined: Jun 24, 2002
Posts: 90
In java exists two type of exceptions (checked and unchecked).
Usage of one type of exception - checked by compiler (must be
declared in function definition).
For Error(=unchecked exception) the declaratons can be skipped.
You can catch Error in the same way as Exception.
When exception raise, it spread using current call stack -
function by function, until some function catch it.
If exception go out main function it will stop the program,
and print call stack and type of exception.
[ March 02, 2004: Message edited by: Igor Ko ]
Dirk Schreckmann

Joined: Dec 10, 2001
Posts: 7023
Errors can be caught, but they usually represent problems that the program is not supposed to handle - things that are outside the control of the program. As such, the general beginner advice is to let them go (and crash your program). Then study any error messages that are displayed, and perhaps figure out how to avoid the error in the future.

[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Dirk, I'm so glad you made that qualification that it's good to let programs die and display stack traces as "general beginner" advice. That bit is often left off and I wonder if people think we should let production Swing apps die on the desktop because there was a null some place.
Learn to love the stack trace. It's a great tool for figuring out what went wrong. Later, when you give your programs to real users, bulletproof it by catching everything before it falls over.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Chandra Bairi
Ranch Hand

Joined: Sep 12, 2003
Posts: 152
hello dirk,
I could not understand what you meant when you said let the errors propogate and program die. Does that mean that we should not catch errors and we should let them crash the application. One thing is for sure that these errors which occur cannot be resolved because they are out of the program control. But why should we atleast catch them and display proper message or at least stack trace with errors.
Am i making sense?
Igor Ko
Ranch Hand

Joined: Jun 24, 2002
Posts: 90
It depends....
For simple or learning program you can do nothing with it, and see
stderr output of ended program.
If your program - server running in remote computer, you can cath all
error/exception and save it in log file (by Logger or log4j functions).
,and continue processing the next incoming requests.
And sometimes them read it, from your remote computer.
If your application control some important hardware, after severe error,
you can switch to reserve simplified ("pilot") version of the program.
If it's big project, written by 100 programers, it is not practical to
crash all program after some simple errors (null pointer exception) in some
It likes as big house will crash as result that a window was broken.

[ March 03, 2004: Message edited by: Igor Ko ]
sever oon
Ranch Hand

Joined: Feb 08, 2004
Posts: 268
Actually, in my experience errors usually do crash industrial grade applications. The only difference is, in a real world app the there is some top-level error handler that would typically try to log the problem and exit gracefully, perform any clean-up, close sockets, etc.
Usually an error is thrown because something went wrong that your program will not have the capability to fix. For instance, how would your program handle an OutOfMemoryError and be able to continue executing? It can't--the only thing you can do is save files, close sockets, and exit with an explanation to the user of what happened.
To be able to handle this error, your app would have to be written such that it uses memory irresponsibly until it catches this error, and then says, ok, I'll behave and starts using memory reasonably. So, the solution is to have your app use memory responsibly all the time so the error will never occur in the first place. It is only in the most extenuating circumstances I can see the former approach making sense.
I agree. Here's the link:
subject: Can we catch Errors...
It's not a secret anymore!