aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Exception Handling! 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 "Exception Handling!" Watch "Exception Handling!" New topic
Author

Exception Handling!

Vikas Sood
Ranch Hand

Joined: Sep 03, 2002
Posts: 109
Hi Friends,
I am handling all the possible exceptions propogated to controller of my MVC implementation.
I have made use of an ErrorDialog class to display messages to client.On click of a button in this dialog user can get to see the cause of exception( retrived by getMessage() method.
I am also sending a System.out to console with exception info.
In one of the error ecenarios i am required to exit the client application after showing the error message to client.So as to achive this i am using System.exit(0).
Are the above approaches ok for exception handling.kindly comment.
VikasSood
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Vikas,
If you're using jdk 1.4, you might consider using the logging facility. Also, it's questionable if you really want to display programming exceptions to end users. It's probably a better idea to tell them that there was a problem, and the log the details of the exception.
M


Java Regular Expressions
Vikas Sood
Ranch Hand

Joined: Sep 03, 2002
Posts: 109
Hi Max,
Thanks for your reply.
I am not showing programming exceptions directly to the client,on encountering an exception i first show the client an dialog with a message with error explaination and two buttons, an "ok" button and another "Error info" button,if the client so requires he can see the exception details as reported by pressing the "Error info" button which pops up an error dialog displaying error message in a text area.
And for reference i am also printing out the error to the command prompt.Another question can we be having the error or other messages printed out to the console.
I will certainly check out the new logging facility now provided by 1.4 jdk, for logging errors instead of showing them on the console.But i think on demand access to error can be allowed to client,can you also provide me with some thoughts of yours so as i am able to decide on this matter.
VikasSood
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
ok, now I see where you're coming from. The error dialog is ok, IMO, but I probably wouldn't have done it. it's just one more variable that could go wrong, and it doesn't really help the client: does it matter if the reservation person knows that there was a RemoteException?
regarding logging: I would suggest doing it liberally and often. And I would suggest logging to the console(not a file), just to avoid any last minute File IO problems.
All best,
M
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
and it doesn't really help the client: does it matter if the reservation person knows that there was a RemoteException?
Not a lot. However this may be useful later to whoever is handling support for this program - they can ask a user over the phone what the error message says. Of course, they can also direct the user to find a log file and read the last few entries in that, or more likely just e-mail the thing to a designated support address. A future enhancement to our program might have an automated "Send error info to support@wherever.com" feature to take care of this. (Not in our version of the program of course; this is a hypothetical "if this were a real product".)
regarding logging: I would suggest doing it liberally and often. And I would suggest logging to the console(not a file), just to avoid any last minute File IO problems.
I'd advocate both. In fact the default behavior for Loggers is pretty good - log WARNING and above to the console; if a FileHandler is added, it defaults to logging INFO and above. It can be useful to have a written log, as in the example above. Last minute file IO problems? Well, the worst-case scenario seems to be that I get some error messages on my console complaining that the logger can't access the desired file. After the initial message, things still function normally; I just don't have a log file. Doesn't seem like a big problem. I'd rather try to make the log file, because it can be pretty useful if users do experience errors of some sort. Be sure to test the final deliverable carefully, that it can be installed in a fresh directory with no complications.


"I'm not back." - Bill Harding, Twister
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Jim Yingst:
and it doesn't really help the client: does it matter if the reservation person knows that there was a RemoteException?
Not a lot. However this may be useful later to whoever is handling support for this program - they can ask a user over the phone what the error message says. Of course, they can also direct the user to find a log file and read the last few entries in that, or more likely just e-mail the thing to a designated support address. A future enhancement to our program might have an automated "Send error info to support@wherever.com" feature to take care of this. (Not in our version of the program of course; this is a hypothetical "if this were a real product".)

Whoa, you're getting pretty serious about this thing: hell, maybe we can sell it .

regarding logging: I would suggest doing it liberally and often. And I would suggest logging to the console(not a file), just to avoid any last minute File IO problems.
I'd advocate both. In fact the default behavior for Loggers is pretty good - log WARNING and above to the console; if a FileHandler is added, it defaults to logging INFO and above. It can be useful to have a written log, as in the example above. Last minute file IO problems? Well, the worst-case scenario seems to be that I get some error messages on my console complaining that the logger can't access the desired file. After the initial message, things still function normally; I just don't have a log file. Doesn't seem like a big problem. I'd rather try to make the log file, because it can be pretty useful if users do experience errors of some sort. Be sure to test the final deliverable carefully, that it can be installed in a fresh directory with no complications.

it can get a little trick: the log files get locked, there are potential IO problems, there are space issues, sometimes there are unsightly messages, etc. If this were a real application, I'd agree 100% percent. As is, it might be good idea to consider letting logging to the console be sufficient. A LogHandler can always be added later, and fairly innocuously.
M
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Whoa, you're getting pretty serious about this thing: hell, maybe we can sell it
I just figure, I want the log file functionality for myself because I benefit from it now; that's enough justifiction for me to put it in. I can also imagine uses for it later for the customers. So if it's not too much work to keep it in for the customer as well, I'd do so; we're supposed to support future enhancements after all. But on reflection you're right in this case - there are enough possible complications that it's not worth the trouble. I can get the logging I want just by editing logging.properties; clients will have their own logging.properties (which by default will have no FileHandlers), and if someone wants to modify this later, they can do so.
So see, I do occasionally accept your advice rather than continue to argue about it.
Vikas Sood
Ranch Hand

Joined: Sep 03, 2002
Posts: 109
hi Max and Jim
Thanks for your discussion.It has helped me come down to a decision.I am gone continue with the error dialog as explained in my post above, and will also be sending out error messages to the console through System.out.printlns.
Am now going to move on to the final stage of user and design documentation now.
VIKAS SOOD
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Exception Handling!