tags:

views:

153

answers:

4

I'd like to differentiate between errors that happen because something is messed up in system (eg. a file is missing) vs. erroneous behavior on behalf of user (eg. selecting too many items in the GUI for some command).

Is there something like "UserMistakeException" (Either in JavaSE or Eclipse API-s) that programmers tend to throw in these cases? I would then present this kind of errors differently.

+4  A: 

I'd say exceptions are like their name says, something exceptional and not something that happens during normal use of the program. Normal use will include some possible mistakes done by the end user. User input validation is a totally different issue and you should simply prepare for errors made by the user in a way that doesn't require throwing any Exceptions.

teukkam
I think it's debatable whether user mistakes should be considered as normal flow of the program. At least, it's easier to focus on the main program logic, if you can temporarily ignore the possibility of user mistakes. Still, I think that your point is valid and there may be better ways to structure my program.
Aivar
I guess the main point I was going for is that the exception throwing and catching are pretty heavy operations and should be saved for cases where there doesn't exist a more graceful way to prepare for a possible error.
teukkam
well, user mistakes are also quite heavy stuff -- CPU can hopefully process exceptions faster than user can produce them :D
Aivar
@Aviar No, it's not debatable. If you write interactive software you have to handle the users interactions.
DerMike
@DerMike, sure I'll handle them, using exceptions :) Well, actually I understand, that there are plenty of "best practices" guidelines that disallow doing things that appear alright :p
Aivar
Handling user interaction with exceptions is like closing down a highway lane with a minefield.
Carlos
If I were given the task to maintain software where user mistakes are handled this way, I'd search for things I can throw at the original developer.
teukkam
+7  A: 

No, there is no such exception. And I do not see an exceptional situation when an user selects something that is selectable.

You'd rather rethink your interaction design. May be you should prohibit selection of too many items. You could allow selection but prevent execution by disabling some buttons.

But tell your user what is going on in every case.

DerMike
Good point, i considered this solution also. The bad thing with disabled GUI-items is that it may be unclear to user why they're disabled.
Aivar
@Aivar The way you present your message depends on the system we talk about. On a website you may use banners. For quite rare events in desktop apps you might use MessageBoxes... Just file another question on SO :-)
DerMike
+3  A: 

In my application there is a custom exception (extending RuntimeException) which I have created for situations like this. When this kind of exception has been thrown. the client will display the message to the user in an error dialog. All other exceptions cause a generic dialog to be displayed, with Details button, which allows the user to see the stacktrace and send it to me. I don't think Java contains any exception type suitable for this, so you have to create your own.

However, I completely agree with the other answers on that the user interface should prevent so called "user mistakes". Preventing errors is one of the basic rules of usability. If the user selects too many items, the client should validate that, display it in a meaningful way and not throw an exception. In my application the special exception type is only for cases where the UI couldn't validate the data properly before sending it to the server. Actually getting the custom exception is now very rare.

Carlos
+2  A: 

If it is a user mistake, then your program should try to get the user to correct it. (If there is something wrong with the file I chose, then tell me what is wrong and ask me to try again. If I selected too many items, then tell me how many items I need to deselect.)

As a human being user, I am not prepared to catch Exceptions, so don't throw them at me.

emory