Re: Repositories, package dependencies, and domain-flavoured exceptions

Jason Che-han Yip wrote:
> hansewetz@xxxxxxxxxxx wrote:
>
> ...
>
> > In your case the exceptions belongs to the business object layer. This
> > should not cause a problem since the access layer should only invoke
> > business functionality through business processes. There should be no
> > need to access the business object layer directly from the access
> > layer.
>
> ...
>
> In this particular case, the "access layer" needs to be able to access
> the exceptions in order to determine how to present them. How would you
> propose to resolve that, given enforced dependency restrictions (access
> -> business process -> business object) and placing domain-flavoured
> exceptions in the business object layer?

The process layer must know how to interpret failures. Different
processes may interpret 'failures' differently. In short, the
process layer will map your exceptions to something that makes sense in
the context in which the process is running.

Notice that I only addressed issues related to dependencies in your
project. I did not address issues related to the correctness of
throwing exceptions or not.

I would suggest that you also take a look at Mr. Lahman's email. He
points out, more eloquently than I can, that the context of a client
determines the semantics of 'failures'.

I would also take a look at failure and error management in general.
It's important to distinguish between normal processing logic,
technical failures and bugs in business rules. It is also important to
map the different types of problems into technical constructs in a
consistent way.

It seems questionable if it is appropriate to throw an exception in
case an Account is not found. If the application is mission critical
and the Account MUST exists it may be the case that the application
should be terminated. The reason is that if the account MUST exist and
you fail to look it up, your system is in an inconsistent state.

If a failure to look up an Account is normal predicted behavior, it is
probably a bad idea to throw an exception. One of the few cases where I
can see exception as a way to handle predicted behavior is management
of optimistic locking failure in transactional applications.

Regards,
Hans Ewetz

.

Relevant Pages

  • Re: Variable naming problem
    ... exceptions to represent any result which is semantically negative. ... his section on using exceptions to represent exceptional conditions, ... failures in general from exceptional conditions? ... it's not reasonable to think we'll often encounter an execution path ...
    (comp.lang.java.programmer)
  • Re: contracted exceptions
    ... exceptions", and followed by "use the debugger to stop on such failures". ... Consider OS design. ... enough to survive each others fault. ...
    (comp.lang.ada)
  • Failure vs. Exception in ApplicationBlocks
    ... I would like to use ExceptionManagement to log exceptions and failures into ... my Event Log. ... I have no problem w/ logging exceptions but how do I log ...
    (microsoft.public.dotnet.languages.vb)