aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Handling runtime exception (and its sub classes) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Handling runtime exception (and its sub classes)" Watch "Handling runtime exception (and its sub classes)" New topic
Author

Handling runtime exception (and its sub classes)

Norbert Lebenthal
Ranch Hand

Joined: Sep 23, 2010
Posts: 74
hi

the last point I stumble upon in my code is that I don't handle at all RuntimeException and its sub classes. So if some NPE or IllegalStateException or whatever is thrown anywhere, the ui just feels stuck (nothing happens, for no visible reason, while something is written in the standard error output).

Have you done something for it?

Personally, I'm pondering to write in each of my business servicer something like:


with UnexpectedProgramException being a checked exception.

On the ui side I could then display a proper message for it, like "An error occurred, please try again. If the error persists, please contact support".

I've the risk of such RuntimeException because I throw IllegalStateException there and there, and so I would prefer to handle them somehow rather than to let the user in the dark with an unresponsive app.

:$

++
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

Howdy, Nono!

Well champ, it isn't a good practice to catch RuntimeExceptions. Can you point out a scenario where a NullPointerException could happen? I can't think of any, partner. Also, if one happens, then it means that the API was used wrongly, so if you do everything correctly, then you shouldn't worry about them.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

It depends on the type of RuntimeException. I throw IllegalArgumentException and IllegalStateException if e.g. wrong parameters are passed, methods are invoked in wrong order,... These exception does not need to be handled, because they must NOT occur in the application, because that would indicate that a developer has made a mistake, which is something a user can't recover from. These bugs should be discovered (and solved) during the testing phase. Just like with a NullPointerException.

It's another story when you have a RuntimeException which is thrown when the database could not be read (initialized), because a wrong database file is provided. This exception should be caught and handled appropriately, because this error can be handled by the user (selecting another database file will solve the issue).


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

Roel De Nijs wrote:It's another story when you have a RuntimeException which is thrown when the database could not be read (initialized), because a wrong database file is provided. This exception should be caught and handled appropriately, because this error can be handled by the user (selecting another database file will solve the issue).


Hum... I think that, in this case, it is worth to create an exception (or hierarchy of exceptions) that extends Exception. I woudn't throw a RuntimeException if the path provided is invalid.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

Roberto Perillo wrote:Hum... I think that, in this case, it is worth to create an exception (or hierarchy of exceptions) that extends Exception. I woudn't throw a RuntimeException if the path provided is invalid.

True (and that's what I did too). But maybe you have to opt for a RuntimeException, because with a checked exception you can not implement the must-implement interface...
Norbert Lebenthal
Ranch Hand

Joined: Sep 23, 2010
Posts: 74
hello again you both

thanks for your answers!

I agree it would be protecting the user about developer errors.... But then isn't it the core of IT anyway? The user isn't responsible if testing wasn't done properly enough, the application should always, at least, inform about the issue.

When a web application fails because something has gone wrong, do you like to see the stack trace in your browser ? Or an Error 505 message ? Or even worse, and closer from the current situation, do you like to do something and then that nothing happens, no knowing whether it's intended or not ?
David Byron
Rancher

Joined: Jan 20, 2009
Posts: 172

The spirit of a Checked Exception is that recovery within the logical universe of the application is possible.

The spirit of a Runtime Exception is that something unforeseen or catastrophic has occurred that disrupts the logical universe of the application so that recover is not possible.

Catching the latter and turning them into the former is kind of like trying to hang a curtain over a rift in the space-time continuum. There's no use pretending that everything is peachy when in fact all bets are off.

If the application hangs, that's a severe bug (likely an error in logic) that ought to be fixed, not hidden.


SCJD 6, OCPJP7, Baroque Potion, G+
Norbert Lebenthal
Ranch Hand

Joined: Sep 23, 2010
Posts: 74
David Byron wrote:
If the application hangs, that's a severe bug (likely an error in logic) that ought to be fixed, not hidden.


informing the user a severe bug happened and letting him choose what to do know (like trying again or going at his IT staff) doesn't fell like hiding, does it ? It's really about getting the bug fixed and letting the user knows what's happening.

anyway, I want to finish this stuff, so I won't add this feature, since it looks like none did it and some got 100% right.

in the end, it feels surprising to me: showing user friendly error page rather than a stack trace or, worse, hanging, is considered a good practice in web applications and web application frameworks (like wicket for example).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Handling runtime exception (and its sub classes)