in which namespace / package to put exceptions

Question

Hi

What is the common or best practice to structure the location of your exception classes?

Let's say you have the packages/namespaces myproject.person (models and DAOs for persons) and myproject.order (models and DAOs for orders) and the exceptions PersonException and OrderException. Should I put the exceptions in their corresponding packages or in a separate package for exceptions (e.g. myproject.exceptions)?

The first approach seems more reasonable (because it's sorted by functionality). But there the question arises where you should put exceptions that are related to both? e.g. a ConstraintViolationException

Thanks

Answer 1

In my experience it is best to put exceptions into the packages that make sense for that exception. I wouldn't create a special package just for exceptions - the exceptions should live near the classes that use them.

Answer 2

Do what the Java class library does. Put the exceptions in the same packages as the API classes and interfaces that throw them.

Answer 3

I would put them in the same namespace as their corresponding classes. For more general exception types you should try to put them in the most specific namespace which covers the classes that use them, so ConstraintViolationException would go in the myproject namespace.

Answer 4

I just keep all the exceptions in the project namespace (ie myproject). They can take up space in a project view if you create one file per class, so I usually call the file (exceptions).cs so that they appear at the top, and place all the execeptions in one place.

If it is a big project, then generally a break the assemblies up into different namesspaces and each namespace will get its own set of exceptions, but we are talking over 100 classes per assembly.

Answer 5

If exception uses only for one class or functuionality group of classes put it near them. If Exception have the common meaning for the application jr library, put it in its oun namespace. IMHO

Answer 6

The problem I have with this whole idea is that exceptions should generally be designed along the lines of what can go wrong, such as NullPointerException, whereas PersonException seems to refer to the object involved in whatever disaster is unfolding without giving a clue as to what went wrong. Did the Person object cause the exception? Is it because the Person has an internal logic problem, or because bad arguments were supplied to one of its methods? Or was the exception due to the Person not being found in the database?

The fact that you are in two minds about exceptions pertaining to both objects merely reinforces my concerns. I suggest rethinking the design of your exceptions (EntityNotFoundException, BadArgumentException, MinorCannotOrderPornException) and the answer to your dilemma will hopefully be more obvious.

Answer 7

Imagine that each assembly has its own operations, and many types of exceptions (not just PersonException or OrderException, but PersonInvalidDataException or PersonDataPersistException). Those exceptions could implement a BaseException, that logs and send emails, for example.

So the more affordable way (in my opinion), is separating them by namespace.