GeeCON Prague 2014*
The moose likes Beginning Java and the fly likes Exceptions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Exceptions" Watch "Exceptions" New topic
Author

Exceptions

shaf maff
Ranch Hand

Joined: Sep 07, 2008
Posts: 180
Hi Guys,

What would be a better way to handle exceptions:



And finally, what would the user see if an exception was thrown ? Would he see the stack or would he simply see the 'cannot connect to db' ?

Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10426
    
    8

I would say it depends on the situation.

Usually in Swing, I prefer having custom exceptions which wrap the actual exception.
The custom exceptions have title, brief description and possible work around as fields.
These are picked up by the ExceptionHelper class and processed in a JDialog.
So the stack trace and stuff is hidden from the user (not all users are technically inclined)
What they do get is a brief description of what the problem is and the solution if any. Good usability that way.


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

How about method 4, "None of these?"

You're catching a SQLException and then immediately throwing a new SQLException with far, far less information in it. The one you catch includes information about exactly where the error occurs, and a message that explains exactly what happened. The one you're throwing incorrectly will say that the error occurred at this "throws" line, and the message will be useless for diagnosing the actual problem!

So in this particular case, the best alternative by far would be to delete the try and catch blocks altogether, and simply let any SQLExceptions that are thrown propagate to the caller.

Now, if this were a slightly different situation where the type of exception you're catching and the one your throwing are different -- ile., you want to catch SQLException but rethrow as a IOException, then please always do this:



Note how I've passed the old exception as a constructor argument to the new exception. This exception is called the cause of the new exception, and it's accessible by calling getCause() on that IOException object. That way if someone catches that IOException, they'll be able to find out what the real problem was.


[Jess in Action][AskingGoodQuestions]
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10426
    
    8

@EFH
I am a bit confused here.
In a distributed system, shouldn't all exceptions be logged and some user friendly message propagated to the user?
I mean, imagine who is not computer savvy, trying to login to some site. The login failed because the DB is unreachable.
Whats the point in propagating the actual exception back to the user? Shouldn't they get some user friendly message like the "pants down" we have at the ranch?

Man,
You are not going to believe this.
I hit submit and got the "Ack! ...pants down.." page!!!
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19697
    
  20

Maneesh Godbole wrote:@EFH
I mean, imagine who is not computer savvy, trying to login to some site. The login failed because the DB is unreachable.

But only the original message contains information on why the login failed. That information is stored in the message only most of the times. Whether the DB is unreachable, my login is rejected or any other error, the exception is always SQLException. The error code may be able to help you, but as the API says: it's vendor specific. You would need a mapping for each database type you support.

I usually use the nasty exceptions, then modify it appropriately in the user interface if possible.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Maneesh Godbole wrote:@EFH
I am a bit confused here.
In a distributed system, shouldn't all exceptions be logged and some user friendly message propagated to the user?
I mean, imagine who is not computer savvy, trying to login to some site. The login failed because the DB is unreachable.
Whats the point in propagating the actual exception back to the user? Shouldn't they get some user friendly message like the "pants down" we have at the ranch?


Sure, at some level. Exactly where and how depends on how complicated the application is. Should you be logging exceptions somewhere down in the bowels of the application where you're able to throw SQLException? Maybe, maybe not; alternatively you can let it propagate to the top of the JDBC subsystem before logging it. Is it the job of low-level code that's throwing SQLExceptions to provide user-level error messages? Certainly not.

But in any case, logging wasn't mentioned here. What the OP is showing is a terrible, terrible, terrible information losing practice; every time I find code in a library where someone has done this -- rethrow an exception losing all the real error information in the process -- I get my thunderbolts out.
shaf maff
Ranch Hand

Joined: Sep 07, 2008
Posts: 180
Maneesh is right. I want to print out a "cannot login" for the user and log the error into server logs.
Anyway, whats wrong with throwing a new exception ?
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

shaf maff wrote:
Anyway, whats wrong with throwing a new exception ?


Two reasons: maintainability, and separation of concerns.

1) The original error message and the original source file name and lline number at which the original error occurred are all lost. When something goes wrong with the application, how are you ever going to figure out what?

2) Your boss says the database code is going to be reused in a separate application, for which an entirely different UI will be necessary. How are you going to handle it, given that the error messages are being generated by low-level code?

3) It's the next day, and now your boss says you have to provide a UI in twelve different languages. How are you going to do that, again, with the low-level database code providing the error messages?

And did you even read what I wrote about the "cause" of an exception?
shaf maff
Ranch Hand

Joined: Sep 07, 2008
Posts: 180
Ok. But wouldn't the e.printStackTrace(); or e.getMessage() print to logs anyway ? So you throw the exception with a basic error msg and then print the stack to server logs like:

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39095
    
  23
Try that line; I don't think it will compile.

Have you actually read what Ernest said about SQL Exceptions and the additional data they encapsulate?
shaf maff
Ranch Hand

Joined: Sep 07, 2008
Posts: 180
I just re-read Ernest's posts, I see now. Thanks guys.

I have two other questions:

1. What is the signifance of specifying that a method throws a exception (public void method() throws Exception{ )? And when should it be used? I have looked into tutorials but its still not clear.

2. I am using the following method to log errors: http://java.sun.com/docs/books/tutorial/essential/exceptions/catch.html
Now, if I want to inform the user that something is gone wrong, how would I go about doing that? The only method I can think of is return-ing a boolean and if false then something is wrong. Is that a good way of handling such issues?
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3833

shaf maff wrote:

1. What is the signifance of specifying that a method throws a exception (public void method() throws Exception{ )? And when should it be used? I have looked into tutorials but its still not clear.




This way you let the exception propagate to the caller, since the caller should handle the exception or propagate it to it's higher level.

SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3833

shaf maff wrote:

2. I am using the following method to log errors: http://java.sun.com/docs/books/tutorial/essential/exceptions/catch.html
Now, if I want to inform the user that something is gone wrong, how would I go about doing that? The only method I can think of is return-ing a boolean and if false then something is wrong. Is that a good way of handling such issues?


That refers to handling multiple type of exceptions in the code. Say the code between try block throws two different exceptions, You may catch a more specific type of exception (FileNotFoundException) in the first block then catch anything else (of course any subclass of IOException) in the other catch block.
 
GeeCON Prague 2014
 
subject: Exceptions