File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Error handling in a GUI Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Error handling in a GUI" Watch "Error handling in a GUI" New topic
Author

Error handling in a GUI

Dennis Grimbergen
Ranch Hand

Joined: Nov 04, 2009
Posts: 140

Hi,

I need a nice way to handle errors in a Swing GUI. Imagine a two-layered application (gui and database). A user clicks a button in the GUI, after which the database performs some action. Let's say a DatabaseException is thrown in the database code. Because I want to show a user friendly exception, I would assume something like this (in the GUI):

From here it's not hard to show this thrown Exception in a alert box or something like that.

While searching the internet for some nice ways I noticed that something like this seems to be common?

Is this a correct way to deal with this? To me it seems not correct to use a static method (showError), from an OO perspective.

SCJP, SCWCD, SCJD
Karthik Shiraly
Ranch Hand

Joined: Apr 04, 2009
Posts: 489
    
    5
The design I usually follow is:

- translate API and framework exceptions to my own application defined (and related to application use cases) exceptions. For example, IOException to DiaryLoadException or DiarySaveException

- propagate these app defined exceptions all the way up so that other layers can take corrective actions if any (may help with requirements yet to come)

- At the highest layer of the application, catch and either log the exception, or pass it onto a view class for display. The display class uses the details in the exception (an integer ID is common in my apps) to form a locale specific error message and display it.

Can't say which approach is 'correct' because it's subjective. The above design has helped keep my apps flexible and extensible.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Error handling in a GUI
 
Similar Threads
Exception catching
Error handling
NX: Persistence in the URLyBird
Remote/local database design. Please comment this.
how to set eclipselink reconnect atampts to one