Question

I’m a IT student, second year. We just learned to program with 3 layers, one for getting data with a class, one for manipulating stuff with requests (all of the methods go in here) and one for the working of the program itself. Seeing as the first two go into classes instead of a form I dont know how to show errors.

Example:
We need to make a login system with a webbrowser and some other stuff behind it. So I make the login in a class, but how to check back for errors? I don’t think it’s normal or even possible to do MessageBox.Show(error); from a class, I can only return stuff, but I want the username/id to be returned if possible.

So in short, what is the best/most accepted way to report errors that are caused by data, so from a class?

Answer 1

Your framework level API’s (eg. your layers) should use Exceptions for real errors, and return values to report non-critical errors.

public class Login
{
    public bool AccountExists(string name) {
        bool exists;

        // do checking

        return exists;
    }

    public LoginResult Login(string name, string password) {
        // Try login
        // If successful
        return LoginResult.Success;

        // What if the user does not exist?
        return LoginResult.AccountNotFound;

        // What about an error?
        return LoginResult.Error;
    }
}

public enum LoginResult
{
    None,
    AccountNotFound,
    Error,
    Success
}

In the example above, you can report the status of operations through return values. For LoginResult this could even be a value type (struct) that contains more information about the result (eg. a string message or something). Because these types of operations on non-critical, there is no necessity for exceptions here. Exceptions are costly and not always necessary to report errors.

Now let’s talk about a different type of error. Logical developer errors. These should be handled by throwing exceptions. Take this example (assume we have some type Account that has a Role property).

public class Foo
{
    public bool IsAdmin(Account account) {
        if (account == null) {
            throw new System.ArgumentNullException("You cannot pass a null account!");
        }

        return account.Role == "Admin";
    }
}

We know as a developer that the account should not be null, so we should check for it and throw an exception if it is. If this exception is ever thrown, its a bug in the calling code and should be fixed not to pass in a null value.

Now that I’ve given two rough scenarios, how does this apply to your question? These are API’s. Whatever your UI layer is, whether it be a WinForm, WPF Window, WebForm, or some other UI, the UI only has to use the API. The API is responsible for reporting information that can be usable by the UI, and the UI is responsible for displaying info in whatever way is best suited for that UI.

The framework API layers should never be responsible for reporting an error to the user with a UI. They should only be responsible for reporting errors to the developer who can take the result, and wire it up to the UI layer in some fashion. You would never display a message box or write to a console from a framework API for example. You would return some result that the UI can use to display its own message.

I highly recommend that you read Framework Design Guidelines. It covers a lot of this material and is an extremely great read.