• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Handling Runtime Exceptions and Fatal Checked Exceptions in the Client

 
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a thin client which interacts with the database via a Business class. I am wondering how people with a similar set up have handled in the client code runtime exceptions thrown from the Business class and checked exceptions thrown from the Business class that indicate something serious has gone wrong in the system?

Runtime Exceptions

In my Business Layer package I have a BusinessException which is a checked exception. I also have subclasses of this BusinessException for particular problems that can go wrong in one of the business methods - for example RoomAlreadyBookedException.

The idea behind my use of several checked exceptions in my business methods is that the client code that is calling these business methods will be able to identify a particular problem and present the end user with an appropriate, user friendly, error message in a dialog.

So this all works nicely. However, I am a bit worried about what will happen when an runtime exception is thrown from the Business Layer. My client code will just end up outputting the error to the console.

I don't think this is a good approach. All problems that go wrong for the client should notify the user via the GUI I think i.e. with an error dialog.

Serious Checked Exceptions

I am unsure too about what I should actually do with the client when it receives either:

(a) a runtime exception or
(b) an checked exception that indicates something serious has gone wrong.

Should I just notify the user that something has gone wrong and let them continue interacting with a potentially corrupt system? Or should I prompt the user that a problem has occurred and then let them know that the application is closing?



Possibly my thinking is going a bit overboard for the purposes for this assignment? But I would love some opinions\advice from how have you guys handled these scenarios in client code?
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I didn't handle runtime exception, because they should simply not occur in a well-developed, well-tested application.

I can't think about any fatal checked exception occuring in the application. The only one which could fit in this category is when the user provides wrong configuration settings and then the user will get a dialog with a user-friendly message and the application simply exits.
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roel De Nijs wrote:I didn't handle runtime exception, because they should simply not occur in a well-developed, well-tested application.


Leaving this assignment aside. I don't think you could approach commercial software like that. There will always be bugs in applications. When they occurr you want your software to behave gracefully. So that is really the reason why I'd like to come up with a good solution now - good to know going forward . I'm sure the markers of this assignment won't care less.

I did a bit of Googling and found setDefaultUncaughtExceptionHandler in the Thread class. Using this will allow you to handle this scenario of exceptions you haven't handled elsewhere (probably because you weren't expecting them). An example of using setDefaultUncaughtExceptionHandler is available on this page here..

It seems like a nice approach. When an unexpected exception bubbles up to the client where you haven't explicitly handled it. You can then log the exception and present the user with some general error message in a dialog. So no nasty stack traces in the command line.

Roel De Nijs wrote:I can't think about any fatal checked exception occuring in the application. The only one which could fit in this category is when the user provides wrong configuration settings and then the user will get a dialog with a user-friendly message and the application simply exits.


The checked exception, RoomNotFoundException, I mentioned on my other thread would be fatal in my eyes. It implies that something serious has gone wrong in the system - some other process has managed to delete a room whilst another process has it locked.
 
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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the application we are developing we have something similar to the setDefaultUncaughtExceptionHandler from the technology/framework (RCP) we are using to develop the application. So I think that's indeed a nice solution, maybe even a bridge too far for this assignment.
 
I knew that guy would be trouble! Thanks tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic