Exception Design

[DeanMc]

This is sort of a design question. I have multiple exceptions that my code base may throw. Currently I have them named based on why they where thrown using System.Exception as the base class.

The downside of this is multiple casts need to be performed or multiple catches in order for this to work. My other option is error codes, this means I have on general exception which passes a string that would be a code of sorts for each given exception

What are all your thoughts on these two options.

[techgnome]

Can you give an example of the different types of exceptions?

What about grouping them? Then providing a sub code?

For instance, the exception type would be a "InvalidFileException" then it could have an enumeration TypeCode that says 1 = Wrong Format; 2 = Unsupported Version; 999 = Unknown/Generic Error

-tg

[DeanMc]

Ah enums, never thought of that, I could house the enum in my <project>.Exceptions namespace. The ones I would have as an example are:

1:FileReadException
2:FileStructureCorruptException
3:UnexpectedParsingException
4otNetToBinaryTypeConversionException
5:FileTypeUnkownException

[techgnome]

The first one I'd probably leave as its own exception the others could arguably be grouped in to a common "FileInvalidFormatException" with a sub-code.

Or... you have FileReadException, as the sole exception type, then your enum could consist of the list as you have it....

-tg

[DeanMc]

Sounds like a plan!

[NickThissen]

Do you actually need to do things differently depending on whether you catch a FileStructureCorruptException or a FileTypeUnkownException, for example?

Why not let all those exception inherit your own custom base exception, like FileInvalidFormatException.
Users can then catch this FileInvalidFormatException, and deal with all the exceptions deriving from that automatically.
But if they do want to handle just one of the deriving exceptions, they can just catch that instead.

If you go with the 'code', and someone would like to handle just one of the possibilities, he would have to do this

try { }
catch (FileInvalidFormatException ex)
{
   switch (ex.Code)
   {
      case 0:
         //...
      case 1:
         //...
      case 2:
         //... etc.
   }
}

If you let all those custom exceptions inherit FileInvalidFormatException instead, people have a choice:

1. Either catch FileInvalidFormatException to catch all of the deriving exceptions at the same time

try {}
catch (FileInvalidFormatException ex)
{
   MessageBox.Show(ex.Message);
}

2. Catch only one or two of the sub-exceptions, like FileTypeUnkownException, and ignore the others:

try {}
catch (FileTypeUnkownException ex)
{
   MessageBox.Show("Unknown filetype!");
}
catch (FileStructureCorruptException ex)
{
   MessageBox.Show("Corrupt file structure!");
}

I think this gives people more control, they can choose which exceptions they want to catch. If you use your 'code' method, people don't have a choice because they are forced to catch all exceptions, or none.

This is also how exceptions in the framework work. There is no one general Exception object that every class throws, just with a different error code. Instead, there are a large number of different Exception classes, and people can catch whichever ones they need.

[DeanMc]

Cheers nick, that is a great idea!