2
votes

I have a Membership exception which looks like this:

public enum MembershipError
{
    EmailNotFound,
    EmailNotConfirmed,
    IncorrectPassword,
    EmailExists
}

public class MembershipException : ApplicationException
{
    public MembershipError MembershipError { get; set; }

    public MembershipException(MembershipError membershipError)
        : base(Enum.GetName(typeof (MembershipError), membershipError))
    {
        MembershipError = membershipError;
    }
}

Should I use an enum in my exception or make an exception for each enum? Because then I would be putting logic when catching the exception like this:

try
{

}
catch (MembershipException exception)
{
    switch (exception.MembershipError)
    {
        case MembershipError.EmailExists:

            break;
            //etc.
    }
}

My service layer throws these exceptions, the web layer/in the action catches these, generate the proper json and return it to the view. Suggest an alternative please?

5

5 Answers

5
votes

Exceptions should only be used for exceptional situations. The errors listed in your enumeration appear to be fairly standard and I would choose not to express them through an exception. Instead I would prefer TryXXX style API over exceptions.

For example

public bool TryGetMembershipData(
  string user, 
  out Data data, 
  out MemberShipError error) {
  ...
}
3
votes

It looks like you are using exception handling for data validation. This is a bad design to begin with. You should be performing these validation checks separately before going through wit the final registration.

1
votes

Bad idea. Exceptions should only generally be used in "exceptional" cases. You will suffer performance issues as well.

0
votes

This may sound not very PC, but I believe that software engineering is not a religion which would force you to observe strict precepts just for the sake of it. There are, of course, theoretical explanations for Dos and Donts, there are tons of Considered Harmful essays, but do they always apply to your own case?

Let's just be pragmatic:

  1. Your MembershipException class is specialized enough, and most of all, it is easy to maintain with it's MembershipError enum.

  2. Also, the cost of exception handling is often overrated: your membership service layer is not a real-time flight simulator after all; a login failure once in a while will not put your application to its knees.

Just keep it like this: simple to maintain and simple to read.

0
votes

To be completely honest that's not the best way to use Exception Handling, the general rule is that you use Exception only when there are happening things you can expect, all the exceptions you are showing here can be perfectly handled like errors. If your service is returning those errors as exceptions there is no much you can do except redoing that layer of your software to return messages with those errors.

If you can't do that then you should be capturing each one of the exceptions on a different catch on your logic layer.