views:

139

answers:

7

Hello..

I'm developing a swing application and I'm a bit confused how can I handle exceptions for example lately a part of my code rename files, So when I was testing it I came up with a "you don't have permission to rename file" as I got it from print exception message. So How Could I express this message to user? and should I use JOptionPane message or just show it on the status bar?

Thanks

A: 

Use Try-Catch handling...

http://tutorials.jenkov.com/java-exception-handling/basic-try-catch-finally.html

When you catch the exception you can do whatever you want with it. Display it to the user, do something else in the code, display another message to the user based on the exception, etc.

Scott
The question wasn't "how to catch exceptions?" but "how display exceptions to the user in my GUI?".
Colin Hebert
but that's what the OP is asking!
Jason S
@Jason S - Look at the title. "in user friendly way" does imply the OP already knows how to catch them.
Ishtar
@Ishtar: My comment was directed towards Scott's answer, not Colin's comment. We must have commented about the same time.
Jason S
@Jasos S - Woopsy! sorry.
Ishtar
-1: earlier comments say it well.
Geoffrey Zheng
A: 

If you catch the expression (enclosed in a try - catch - block) you get notified when this exception occurs. Then you have to decide: Is there a way to make things work again? Could you, for example, ask the user for another file name? Then do that! But if there is no sensible way of circumventing the error, then just have the program abort.

Lagerbaer
This doesn't answer the question which was about "how to notify the exception to the user".
Colin Hebert
+6  A: 

From your question it sounds like you already know how to handle the exception in the java sense. However you are looking for advice on how to react to exceptions once you have caught them.

In the specific example you give in your question I (as a user) would want that error presented quite clearly so a JOptionPane may be your best bet. I wouldn't just update the status bar as that is very close to silently failing and the user will just be left confused.

A personal rule of thumb is that if the user is likly to be waiting on the code to complete before getting on with their task then they must be informed of the failure strongly i.e. a modal box. If the failure is in a background task that the user can carry on without caring about, or the code can recover from it, or the code is going to retry, then I would go with the more subtle approach of the status bar or icon change depending on the UI.

Kevin D
Thanks, but another point is that how to print a specific message to the user that best describes the exception.Should I print the exception message?
Feras
I guess that should depend on the exception. If you're fairly certain that it is a permission problem, tell the user just that.However, if it's an exception you haven't anticipated (stack overflow for instance), it may make sense to display the exception
kskjon
This can depend on who your user is, are they technical or not? It also depends on the error, in this specific case the error is quite clear so you could probably just print the error text, in other cases... say a NullPointerException... those mean nothing to the user and as such you should perhaps give a more plain speaking explaination to them with an instruction to check the logs or to talk to the company helpdesk.
Kevin D
+1  A: 

I don't quite understand the first part of your question, but I try to answer the second one. In general, how you want to display an error to the user depends of the software and error. In most cases JOptionPane or similar is appropriate. However, in some cases a modal dialog might be too intrusive and status bar might be a better way to go. But again, this depends on what kind of software you're writing.

Carlos
+1  A: 

If you anticipate an exception could occur as a result of a user action, then you should explicitly catch it at the point that makes sense and ensure your program recovers correctly.

For example if the user can rename a file, you might invoke a rename() method which returns a status code to indicate success or a failure error code. Inside the method one of these codes might actually be triggered by an exception but the calling code doesn't care. Once the call returns, the status code can be used to determine which error message to show (if any).

  enum RenameStatus {
    Success,
    Failed,
    SecurityFailed
  }

  void doRename(File fromFile, File toFile) {
     switch (rename(fromFile, toFile)) {
     case Success:
       break;
     case Failed:
       // todo generic dialog rename operation failed
       break;
     case SecurityFailed:
       // todo security dialog rename operation failed due to permission
       break;
     }
  }

  RenameStatus rename(File fromFile, File toFile) {
    try {
      if (!fromFile.renameTo(toFile)) {
        return RenameStatus.Failed;
      }
      return RenameStatus.Success;
    }
    catch (SecurityException e) {
      // Error - permission error
      return RenameStatus.SecurityFailed;
    }
    catch (Exception e) {
      return RenameStatus.Failed;
    }
  }
locka
I afraid this doesn't answer OP's question.
Colin Hebert
+2  A: 

To elaborate on a comment made by Kevin D - it really depends on your expected user audience. If they are technically proficient you can use the exception text as is. If not then I would prefix the message with "An error has occurred, please contact your technical support personnel with the following information: " then append the error message and ideally a unique identifier for locating an associated log entry... I often use a timestamp for this.

If you really want to get fancy you can email the tech support people with much more detail like the exception and full stack trace, copy of log entry, etc. I have done this in the past but you have to be careful as a frequently occurring error will quickly flood an inbox :)

Of course if the error can be fixed by the user then you can just say so (and how to do so) in your message. That is about as thorough and fancy as you can get...

BigMac66
Totally agree with you
Kevin D
A: 

File permission is kind of a "normal" exception, not a truly "exceptional" one as "disk full" would be, so you'd probably just use JOptionPane instead of sending an error report. That being said, some earlier answers are very informative and should be adopted for the general cases.

In addition, my main() always start with this:

Thread.setDefaultUncaughtExceptionHandler(new UncaughtExceptionHandler()
{
     public void uncaughtException(Thread t, Throwable e)
     {
         // do your things: see earlier answers
     }
}
Geoffrey Zheng