in which namespace / package to put exceptions?

Question

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

Kao

Answer 1

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.

Hundredweight

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.

Jackofalltrades

Answer 3

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.

Suppression

agree, create folder Exceptions and add everything related to them there. Exceptions naming also should be readable and objects related, like f.ex FieldMissingValueException – Addia

Answer 4

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

Philoctetes

Answer 5

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.

Lilith

Answer 6

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.

Windblown

Answer 7

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.

Synapsis