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.
Chandra Bairi
Ranch Hand
Posts: 152
posted 14 years ago
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!