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?? regards, shekar.
Error... 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 ]
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.
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
Joined: Sep 12, 2003
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? Regards, shekar.
Joined: Jun 24, 2002
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 subsystem. It likes as big house will crash as result that a window was broken.
Etc... [ March 03, 2004: Message edited by: Igor Ko ]
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. sev