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?

  • 2
    It would help if you posted a little sample code. I misunderstood the question. Commented Feb 27, 2013 at 14:51
  • 1
    It's not really a programming specific issue but more of design problem. Commented Feb 27, 2013 at 15:16

3 Answers 3


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.

  • That makes sense. So basically let the code calling the method handle the exceptions thrown on error? Very nice explanation you provided too btw. Commented Feb 27, 2013 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. Commented Feb 27, 2013 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."
    – user40980
    Commented Feb 27, 2013 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. Commented Feb 27, 2013 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
    Commented Feb 28, 2013 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.


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").


  • 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. Commented Feb 27, 2013 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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