4

Possible Duplicate:
Create custom exception or use built-in exceptions?

Hi,

In program design, is it normal to model exceptions for business constraints? E.g. if xyz must be >1 in order to get abc (a basket object must exist before being able to add objects), and the basket does not exist, is this a good enough reason to have a custom exception to model this real-world scenario?

What reasons contribute to using custom exceptions?

Community
  • 1
  • 1
GurdeepS
  • 65,107
  • 109
  • 251
  • 387

5 Answers5

2

I think the question is not whether one should create a custom exception class, but whether one should use exception for normal conditions of incorrect input, i.e. if you ask a user to create a new password, should the code internally throw PasswordTooWeakException (or InvalidArgumentException) when the password is too weak, or should handle it in another way. If that is the question, my answer is no, you should not use exceptions in this case. Exceptions are for exceptional cases only, i.e. error situations, where something not expected happens.

MK.
  • 33,605
  • 18
  • 74
  • 111
1

If the basket does not exist, sounds like a ArgumentNullException or an InvalidOperationException depending whether the variable is a parameter or not. If xyz must be greater than 1, sounds like an ArgumentException. The latter case also sounds like something you could handle without resorting to exceptions depending upon where the validation is taking place.

There are many of already defined exceptions as part of the standard library. My advice is to rely upon those until you can clearly demonstrate that such exceptions truly do not cover your particular scenario.

the_drow
  • 18,571
  • 25
  • 126
  • 193
Anthony Pegram
  • 123,721
  • 27
  • 225
  • 246
  • 2
    You pretty much should never throw NullReferenceException. It's pretty specific -- it's to be thrown when a null is dereferenced. For other uses, ArgumentNullException or InvalidOperationException are more appropriate. – Adam Lear Jan 17 '11 at 16:13
0

I use custom exceptions when I plan on treating them differently (or think they should be treated differently). For many situations, the general exceptions with a good message are good enough.

If all you plan on doing in the catch is display the message, then you don't get much out of custom exceptions.

Lou Franco
  • 87,846
  • 14
  • 132
  • 192
  • A good example would be cardoesntstartexception when the car needs to start for the method to do it's intended task. Also, is it reasonable to actually catch exceptions/handle edge cases which are very unlikely? (e.g. a technical user or non-technical user editing the database of a system application). – GurdeepS Jan 17 '11 at 16:13
  • It only matters if you handle that case differently than other exceptions. Beyond the error message being different. Do you start the car for them if it's unstarted? Or do you just tell them? Of course you should handle edge cases -- they will happen. – Lou Franco Jan 17 '11 at 19:15
0

Most of the time, I would recommend an exception that already exists. Like @Anthony says with the ArgumentException. You can always leave a message inside the Exception if you want.

Sometimes, it is handy to have your custom exceptions. For example when you have such code:

catch(ArgumentException e)
{
    if(e.Message.Equals("The argument was bigger than 0"))
        // do something
    else
        // do something else
}

That would result in messy code and maybe a custom event or wrapper exception would be more appropriate.

Maybe you could check this blog as well: http://blogs.msdn.com/b/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

Marnix
  • 6,384
  • 4
  • 43
  • 78
0

It sounds like you are attempting to create exceptions that duplicate the functionality of existing exceptions. For example, your empty basket scenario could be handled by throw new ArgumentException("Basket not instantiated");

When in doubt, fall back to the Exception Design Guidelines on MSDN.

Greg Buehler
  • 3,897
  • 3
  • 32
  • 39