Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When structuring a visual studio solution I tend to structure it so that various components are in different project (As I would assume most people do) I tend to have a bunch of User defined exceptions.
The Question is should these exceptions be in a separate project to the (for example) Model classes?
I tend to put them in a sub-namespace of the model, and organise them in a directory within the Model project. but should they be in a separate project all together?
It depends on how you imagine them being used and how you deploy your application. As a rule of thumb – never create more packages/assemblies than needed.
There’s one strong case for putting Exceptions and Interface classes in their own assembly and that’s when they’re supposed to be shared among clients that not necesarily need to ‘full’ package, one common scenario is when using remoting another is when building plugin architechtures.