Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How should my web application handle common errors such as incorrect password, session timeout, etc.?

I have a class called Hotmail that contains various method such as login, logout etc.

To illustrate the confusion, I have a login method that logs the user into Hotmail via my software. The login method returns a HttpWebResponse object. But, within the login method any number of things could happen such as wrong credentials being entered or a timeout.

I'm in some confusion about how, and where to handle such errors.

In the case of the wrong credentials being entered, or a timeout, it would be pointless, or sometimes not possible to return a HttpWebResponse object. What would be the best way to handle such errors?

Should I create custom Exceptions so the code that's calling the method can check for such errors and handle them?

What's the conventional way to handle these sorts of errors as I'm sure this is a common point of confusion?

share|improve this question
2  
It would help if you posted a little sample code. I misunderstood the question. –  Aaron Kurtzhals Feb 27 '13 at 14:51
1  
It's not really a programming specific issue but more of design problem. –  James Jeffery Feb 27 '13 at 15:16

3 Answers 3

up vote 8 down vote accepted

The conventional way is to return a custom Exception, and let the calling code decide what happens then.

Imagine that your "login" command is packaged as a library, and used in multiple applications. In one application, if there is a timeout, you want to display an error message and give up. In other application, in case of a timeout, you want to retry the method three times, and give up only if all three logins fail on timeout. By providing an exception, you give both applications an opportunity to do what they want.

It may be tempting, but don't try to put both these two options into the "login" command, e.g. by adding a new parameter "howManyRetriesOnTimeout". A third application may want to do something else. Also as a regeneral rule, it is not recommended to put multiple functionality (logging in, repeating on timeout) in a single method.

share|improve this answer
    
That makes sense. So basically let the code calling the method handle the exceptions thrown on error? Very nice explanation you provided too btw. –  James Jeffery Feb 27 '13 at 14:50
1  
@JamesJeffery - Yes. If everything goes right, the method returns a value. If anything goes wrong, the method throws an exception. (If various things can go wrong, the method throws exceptions of different types: WrongPasswordException, TimeoutException; all of them derived from the same type: LoginException. So the calling code can just catch the LoginException and display an error message, or possibly handle the TimeoutException as a special case.) This is the meaning of the exception -- something went wrong, and the method did not do what it was supposed to. –  Viliam Búr Feb 27 '13 at 14:59
2  
+1 -- "it is not recommended to put multiple functionality in a single method" -- a coworker of mine says "if in describing the function you use the word 'and' refactor the and out." –  MichaelT Feb 27 '13 at 15:56
1  
I'm tempted to downvote this on the basis that it's promoting using exceptions for control flow (hopefully we can all agree that's a bad idea: stackoverflow.com/questions/729379/…). I prefer superM's advice on using status codes when you're dealing with user/network errors. –  Baqueta Feb 27 '13 at 16:30
1  
@Baqueta that's completely backwards, the whole purpose of exceptions is to be an alternative to status code checking, which is more tedious and error prone. It is not normal when users enter wrong passwords or connections time out. Also, exceptions are used for exceptional control flow - if they are not used for any kind of control flow like you suggest, what is the point of having them? –  Esailija Feb 28 '13 at 11:28

You should begin by dividing the possible errors into two categories: the ones that the user can possibly fix and the rest. Each of this categories should have a separate approach.

If there is a problem with credentials or the timeout was exceeded, the user should be informed about this in order to take measures. You should show the user a message indicating the problem in a user-friendly manner (i.e. do not print the stack trace).

What comes to creating custom exceptions, this isn't really specific to the type of application you're developing. All the general advice and best practices can be helpful. Also consider using status codes for such errors instead of throwing exceptions.

share|improve this answer

The examples you give are things that require user action. I suggest that you tell the user as clearly as plainly as possible what went wrong and what they need to do.

From the user experience site

Help users recognize, diagnose, and recover from errors - Error messages should be easily read and understood by the users, and should tell them what to do to fix this (e.g don't write "Error 1052" and let the users search the solution themselves, but instead write "We couldn't locate you. Please turn on your phone's GPS under Settings").

http://ux.stackexchange.com/a/17799/21611

share|improve this answer
    
The software I'm developing is Dekstop and Mobile based. I totally agree with you, but the question was regarding the best practice for handling errors should they arrive. –  James Jeffery Feb 27 '13 at 14:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.