How do you prefer to organize exception definitions?
exception, language-agnostic
Solution
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.
Problem
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?