Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Can we catch Errors...

 
Chandra Bairi
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Igor Ko
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Chandra Bairi
Ranch Hand
Posts: 152
  • 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?
Regards,
shekar.
 
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
subsystem.
It likes as big house will crash as result that a window was broken.

Etc...
[ March 03, 2004: Message edited by: Igor Ko ]
 
sever oon
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.
sev
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic