I almost feel embarrassed to ask, but I always struggle with how to organize exception definitions. The three ways I've done this before are:
- Use the file-per-class rule. I'm not crazy about this because it clutters up my directory structure and namespaces. I could organize them into subdirectories and segment namespaces for them, but I don't really like that, and that's not how the standard libraries usually do it.
- put the definitions in a file containing the related class(es). I don't really like this either because then exception definitions are scattered about and may be hard to find without the aid of a code navigation tool.
- One file with all the exception definitions for a namespace or "package" of related classes. This is kind of a compromise between the above two, but it may leave situations in which it's hard to tell which exceptions "belong" to a particular group of classes or set of functionality.
I don't really like any of the above, but is there a sort of best-practice that I haven't picked up on that would be better?
Edit: Interesting. From the "Programming Microsoft Visual C# 2008: The Language", Donis suggests:
For convenience and maintainability,
deploy application exceptions as a
group in a separate assembly. (p. 426)
I wonder why?
I use the following approaches:
- Exception class in a separate file: when it's generic and can be thrown by more than one class
- Exception class together with the class throwing it: when there is only one such class. This makes sense because the exception is part of that class' interface
A variant on the latter is making the exception a member of the throwing class. I used to do that but found it cumbersome.