Question

I was doing a code review and came across something odd which I've never seen before. The developer decided to create a sub-namespace just to contain all the assembly's exceptions.

I thought I had read that this was explicitly not a good use of namespaces and that exceptions should be kept at the "lowest" namespace from which they are thrown, but I haven't found anything on MSDN (or anywhere else for that matter). At the same time, it seems odd that I haven't come across this before in the framework itself or the third party libraries I've used.

Are there any guidelines exist that would push away from keeping all exceptions in a .Exceptions sub-namespace?

Was it helpful?

Solution

The two main reasons for using namespaces are to avoid name collisions, and to add logical grouping. But since exception class names typically have the form "XYZException" (and other classes have not), those two requirements are already fulfilled by this naming convention. Thus adding an additional sub-namespace is unneccessary in a context where everybody follows the convention. It tries to solve a problem which is already solved, adding a needless complexity to the code.

Moreover, to my experience its better to use namespaces for partioning under aspects of your domain, not for technical grouping. When you start to put exception classes into a sub-namespace, the next decision will be to put all enums into a sub-namespace of its own, then all helper structs, and so on. Actually, I don't think this makes code any clearer or easier to navigate in, so I do not think it would be useful.

Licensed under: CC-BY-SA with attribution
scroll top