Yes you can define both at both layers. In fact it is often necessary in both cases. I'm assuming by your question that you're referring to the best practice of keeping business logic in the process layer. This is definitely the right practice. You generally want to avoid putting business rules (and thus business exceptions) inside of an object if its job is to interact with an application.
For example, if you had an object for the Google Search Home Page, your business process might have the rule that you are not allowed to conduct searches with text that matches the format of a social security number. The right place to put this rule in the process flow in BP is in the Process, not the Object. If other business processes need to use that Object, they may not be subject to the same business rules.
However, something to consider is whether the business exception you're talking about is or is not directly associated with the application. If the application itself has a business rule, then that should absolutely be in the object layer.
For example, if your object interacted with an accounting application and that app would throw an error if your debits entered did not match your credits (because they would need to match), then this would be a business exception that must be in the object, not in the process.
Still, depending on the business application, 90% of the time business logic/exceptions should remain in the process layer. System Exceptions could be in either but it is best to build System Exceptions into an object for specific exceptions that you know the app would throw for any Process Automation.
Respectfully,
Dave
Dave Morris, 3Ci at Southern Company
