This week's giveaway is in the Java/Jakarta EE forum. We're giving away four copies of Java EE 8 High Performance and have Romain Manni-Bucau on-line! See 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
posted 14 years ago
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.
posted 14 years ago
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