12

I am creating a C# application and am trying to take advantage of custom exceptions when appropriate. I've looked at other questions here and at the MSDN design guidelines but didn't come across anything as specific as what I'm wondering here.

What is the best practice for how to organize custom exceptions?

For example, I have a class Disk that throws an InvalidDiskException. Disk is the only class that throws this exception.

Currently, I have the exception nested in the Disk.cs file as follows:

Disk.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OrganizingExceptionsInCSharp
{
    class Disk
    {
        [Serializable]
        public class InvalidDiskException : Exception
        {
            public InvalidDiskException() { }
            public InvalidDiskException(string message) : base(message) { }
            public InvalidDiskException(string message, Exception innerException) : base(message, innerException) { }
        }

        //
        // Code that throws the exception.
        //
    }
}

Should the exception be defined at the same level as Disk (ie. not nested within)? Should the exception be nested within Disk but kept it's own partial file? Might there be other, better options? Please let me know if there are other considerations I haven't thought of.

Kyle Tolle
  • 694
  • 2
  • 7
  • 17
  • 7
    Personally I don't see any point in nesting classes unless you're making the nested classes private. If they're public the nesting serves no purpose other than to make external references more verbose. I would generally define each class in it's own file, if only because it makes it easier to browser the structure of the application. Other than that I'm looking at this code and wondering what InvalidDiskException gives me that IOException doesn't? Unless you're going to trap this error specifically what's the point of creating a custom exception here? – James Gaunt Oct 08 '12 at 21:54
  • 1
    I'm with James. Nested classes for me are private classes that are only there for a single purpose within the parent class (to make the parent cleaner). Generally, we place exceptions in their own folder within a given project, however the namespace is the same as where the exception will generally be thrown from. – Simon Whitehead Oct 08 '12 at 21:57
  • James, I was nesting the exception to give the context that this class is the only one that will use it, even though it is public. An invalid disk is one that doesn't have a particular file on it. So this is when `InvalidDiskException` will be raised. It is specifically handled elsewhere, it's just that that code didn't seem relevant here. – Kyle Tolle Oct 08 '12 at 22:06
  • 2
    @KyleTolle if you are throwing it because of particular file doesn't exist the `System.IO.FileNotFoundException` could be used – JG in SD Oct 08 '12 at 22:08
  • Simon, so your folder structure (at least for exceptions) doesn't match the namespaces then, is that correct? I can see a benefit to having all your exceptions in one place, and then going further to have them still namespace'd appropriately. That seems to go against the practice of having your namespaces match your folder structure though, right? I guess you've found it more beneficial than not? – Kyle Tolle Oct 08 '12 at 22:09
  • @JG in DS - That's a good recommendation for this particular case, thanks! The answers/comments here will still be helpful in other instances though. – Kyle Tolle Oct 08 '12 at 22:21
  • If your custom exception does not return any special information on why it was thrown then maybe you should just throw an InvalidOperationException. – Crono Feb 14 '14 at 13:48

3 Answers3

2

I'd define my custom exceptions in {MyNamespace}.Exceptions

Mauro Sampietro
  • 2,739
  • 1
  • 24
  • 50
0

Custom exceptions, IMHO, ought to be in their own independent assembly, for one simple reason: if you wind up throwing them across process/machine boundaries, every process involved might encounter problems (and thus another exception) if they don't share a common understanding of the custom exceptions.

Nicholas Carey
  • 71,308
  • 16
  • 93
  • 135
  • Not sure why the downvotes without comment here -- but in the context you describe wouldn't all the processes involved need to be working from the same set of assemblies, whether or not the exceptions were defined in an assembly of their own? However, if you're stating that the exceptions can independently of the rest of the system and there's a case for deploying them independently ... ? – Tim Barrass Dec 12 '14 at 10:06
0

I suggest having one file/class for each custom exception and placing these files/classes in a project sub-folder called CustomException.

Greg Cowell
  • 677
  • 5
  • 16