• 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
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Handling runtime exception (and its sub classes)

 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

:$

++
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Roberto Perillo
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ?
 
Rancher
Posts: 175
Clojure Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Norbert Lebenthal
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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'm not dead! I feel happy! I'd like to go for a walk! I'll even read a tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic