Win a copy of Emmy in the Key of Code this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

When should I deal (or no deal) with unchecked exceptions? (with example)

 
Ranch Hand
Posts: 74
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys. I'm preparing my ocp certification (that also takes Exceptions topic) but I think is better to make the question here because it's more related with the basis of the topic.

I will try to explain myself with an example that I was thinking: It's common to use IlegalArgumentException in setter methods. So we can have a code snippet like the following:



So up to this point I figure, what if there is another programmer that will invoke setAge() method and cannot see the method's implementation with the IllegalArgumentException?. I mean, thinking in design, it would be better not to use any RuntimeException or turn it to a checked exception because what's the meaning of throwing an exception if you are not obligated to deal with that. In this case is not good ending the program just because someone made the mistake of passing an incorrect age. I'd prefer show a message to the user letting him/her know about what's going on. And to achieve that If I throw a checked exception I'm saying to the other programmer: "If this case happens, you have to let the user knows".

I'd like to know your opinion because I'm a bit confuse with this case. Anyway, if I'm right, what's the real meaning of unchecked exceptions?.

Thanks!
 
Saloon Keeper
Posts: 21229
137
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sooner or later every Throwable must be caught. Exceptions are, of course, subclasses of Throwable. If nothing else catched a Throwable, the JVM itself will, and of course, it will immediately terminate, killing all of its Threads.

In some cases, where things have become positively hopeless - say an OutOfMemory exception, that's for the best. But if you can recover, it's better to catch the exception, report it, repair it. and go on. Exactly where to do that is often the challenge, but as a rule, the best place to catch something is the highest level you can do something about it. Even if that something is simply to wrap another Exception around it and re-throw.

In your case, since you're expecting bad data, I'd create a custom checked Exception - say InvalidValueError. That way the caller would be on alert that passing bad data would have consequences and the caller must be the one to deal with them.

A lot of times in an application, I'll create a base Exception class and subclass it in order to deal with different situations. For example, let's say I created a PersistenceException class that would catch all the various types of JDBC Exceptions that can come from trying to fetch data from a database. I could have my caller listen for this class, but subclass it into things like BadSQLPersistenceException, DataNotFoundPersistenceException, and so forth. These exceptions classes might wrap actual SQLExceptions of various types, allowing my logic to easily distinguish using the instanceof operator in my "catch" clause.
 
Pablo Napoli
Ranch Hand
Posts: 74
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim. Thank you so much for your reply. It was really interesting. If I should take some points about you said, I'd chose these:
* if you can recover, it's better to catch the exception, report it, repair it, and go on.

* Exactly where to deal with an exception is often the challenge.

* The best place to catch something is the highest level you can do something about it.

Now I'm studying the chapter Exceptions and assertions of Ocp study guide and in page 291 about using multi-catch it says: "It is common to log the error and convert it to a different exception type". And in the example it converts an Exception to a RuntimeException:
} catch(Exception e){
e.printStackTrace();
throw new RuntimeException(e);
}

Wouldn't it be a bad practice?. I mean, If i have an Exception is because it's about an important matter and as you said, I want to obligate the caller to deal with this issue. So making this conversion who is gonna call this method might not notice it until the exception happens. It's just my point of view according to what we were talking about.

Thanks mate!
 
Ranch Hand
Posts: 286
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Pablo Napoli wrote:Wouldn't it be a bad practice?. I mean, If i have an Exception is because it's about an important matter and as you said, I want to obligate the caller to deal with this issue. So making this conversion who is gonna call this method might not notice it until the exception happens.



I would not necessarily "draw any straight lines."  What to do/when always boils down to meeting business needs/requirements.  Certification study aids/guides/books/websites aren't always guides of how to do things in the real world, rather their ultimate aim is to help us achieve certification objectives.

For example in OCAJP Associate Java 8 Programmer Certification Fundamentals: 1Z0-808 by Hanumant Deshmukh, there are plenty of "side notes" to that effect.  Example:

Just like the cast operator, the instanceof operator is also used only sparingly in professionally written code. Usage of instanceof reflects a bad design and if you feel the need to use instanceof operator in your code too often, you should think about redesigning your application.



By the way, TH is using instanceof very appropriately.

I hope that helps,
Charles

 
Tim Holloway
Saloon Keeper
Posts: 21229
137
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, it's not at all uncommon to catch checked exceptions and translate them into unchecked ones and vice versa. In fact, I think Spring Data does a lot of that, in addition to normalizing the rather haphazard set of SQL Exceptions into things that are more easy to deal with. Very often you'll do that in boundary methods that that you into and out of subsystems.

Much argument has been made as to the merits of checked and unchecked exceptions, but really, it's almost an art form. Whatever works best for the situation.
 
today's feeble attempt to support the empire
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!