• Post Reply Bookmark Topic Watch Topic
  • New Topic

Catching Errors  RSS feed

 
Sylvain Duchesne
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
is handling errors could be a good practice. In what' situations handling errors could be useful.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In small practice programs, tests, proof of concept or school assignments you might do fine with letting all exceptions bubble up to the JVM and kill the process. The stack trace is a useful debugging tool.

In serious applications you want to catch anything that you will do something about. So if you're converting a user entered string to an int with Integer.parseInt() you might catch the exception and tell the user to try again.

There are some errors that you could do something about, but choose not to. It's rather pointless to catch an exception and do nothing with it. I see lots of catch clauses that log a message and rethrow the exception. If you do that all the time your log will duplicate the stack trace but your app won't behave any better. So I let them bubble up until they hit a method that actually knows what to do with them.

There are some things you usually can't do anything about, like out of memory errors. If you try to pop up error messages or save data or even log the error you may well get the same exception again and accomplish nothing. Because they are so hard to handle, Sun made them extend Error instead of Exception and the compiler does not require you to catch them.

Much of what I've said is opinion and others are free to disagree. Now we'll go into seriously controversial opinion where many are sure to disagree. Some people like to throw custom exceptions that extend Error instead of Exception. That way the compiler won't make them declare them or catch them. They catch all Exceptions from other libraries, like java.io, and wrap them in the custom exception. I tried this style in one application and found it very pleasant, but I had a good high level point to catch everything. Some apps might not have that.

Any of that help? This can be a book length topic, but I'd love to hear what you thought of this so far and what kind of style you think you'd like to try.
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sylvain Duchesne:
is handling errors could be a good practice. In what' situations handling errors could be useful.

Say you want to write a new word processor to replace Microsoft Word. Typically errors will cause the program to halt. Let's say you try to open a corrupt file so the operating system throws an error when you try to open it with your new word processor. Would it be appropriate for the program to just halt? Probably not! Instead, you would handle the error by displaying an appropriate error message to the user.

Granted this is a over-simplified example, but I hope it illustrates that handling errors is indeed a good practice. Similar situations can be found with many types of applications.

Layne
 
Steve Stelting
author
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Sylvain,

I'd like to add an additional $0.02 to the great points Stan and Layne have made. Exceptions and errors have been designed into the Java language to provide a way to communicate problems in an application as it runs. As such, they provide us with an opportunity to intercept and act upon these problems before they propagate to end users and cause an application to crash. (and become a REALLY big problem!)

Normally, we can make a good guess about what problems can occur in an application and why they might occur. Knowing this, we can develop a strategy to address the most commonly occuring errors. The end result? We can handle some errors, adressing common issues that can occur when using software. We can reduce the overall level of customer frustration... and the total volume of support calls as well.

As Stan mentioned, we can also choose a strategy with some problems where we take minimal action - logging an exception but otherwise leaving it alone. For reasons of application stability, we could also design a "safety net", to intercept and log errors that would otherwise be unhandled. [most enterprise servers do something like this]

The key point with errors is that we can choose to use multiple strategies and intelligently handle errors in code. Unfortunately, many developers treat error handling as an afterthought in code, which leads to "gems" of error handling like:



With well-designed technologies such as Java, I feel it's always a rewarding exercise to educate ourselves about how we can effectively deal with error conditions in code. The end result is an application that requires less support and less time spent trying to debug problems with that application during post-release support.

OK, I'm stepping down from my soapbox now. Thank you for humoring me.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!