Business Exceptions v Core Code

[Ian Tebbutt]

I've recently been researching an idea that we write far more code to
handle business exceptions, than we do to solve core business
problems.

For instance in an online retail system we have to write code to
handle a sale - all well and good. But we also have to write code for
stock out, price change, special pricing (customer discount), returns,
incorrect order and so on. Each of these exceptions although a rare
occurence takes just as much code as the core development. And by
their nature these exceptions are not only unusual there are always
more of them to handle than the core issue.

Result is that >75% of code is built to handle business exceptions,
but >75% of design effort goes into the core. And that is a key reason
why so much of our software fails - the code for exceptional
circumstances is not as well designed, and the exceptions themselves
are less understood and have greater variability and complexity.

Now, is there a design pattern, methodology - even a name for this
idea ? Is it new, can anyone help ? Even if only to confirm that I'm
not barking up the wrong tree. If patterns isn't the place for this,
is there anywhere better ?

[Simon Strandgaard]

On Mon, 26 Apr 2004 03:58:42 -0700, Ian Tebbutt wrote:
[snip]
> Result is that >75% of code is built to handle business exceptions,
> but >75% of design effort goes into the core. And that is a key reason
> why so much of our software fails - the code for exceptional
> circumstances is not as well designed, and the exceptions themselves
> are less understood and have greater variability and complexity.

Bouncer Pattern may help you, separate exception bailout from the core
code, hopefully making the core more readable.

Have a look at the methods prefixed with 'check_'..


def check_not_endofinput(context)
return if context.input.has_next?
context.raise_mismatch("(Inside) end of input")
end
def is_member_of_set?(symbol)
@set.each do |i|
return true if i.kind_of?(Range) and i.include?(symbol)
return true if i == symbol
end
false
end
def check_member_of_set(context)
symbol = context.current
return if is_member_of_set?(symbol)
context.raise_mismatch(
"(Inside) symbol #{symbol.inspect} is not in set #{@set.inspect}")
end


Now comes the core code.. as you can see all exception
throwing is easy to overview.


def match(context)
check_not_endofinput(context)
check_member_of_set(context)
context.input_next { @succ.match(context) }
end


Were this what you were looking fore ?

--
Simon Strandgaard

[Shashank]

Hi Ian,


> I've recently been researching an idea that we write far more code to
> handle business exceptions, than we do to solve core business
> problems.
>
> For instance in an online retail system we have to write code to
> handle a sale - all well and good. But we also have to write code for
> stock out, price change, special pricing (customer discount), returns,
> incorrect order and so on. Each of these exceptions although a rare
> occurence takes just as much code as the core development. And by
> their nature these exceptions are not only unusual there are always
> more of them to handle than the core issue.
>
> Result is that >75% of code is built to handle business exceptions,
> but >75% of design effort goes into the core. And that is a key reason
> why so much of our software fails - the code for exceptional
> circumstances is not as well designed, and the exceptions themselves
> are less understood and have greater variability and complexity.
>

CORBA has brought Exception handling at design level. i.e. when you design
an interface(and operation signature) you also design exceptions that can
be raised when this operation is invoked.
Application code is allowed to throw only the exceptions designed in IDL (
place where interfaces are declared).

So that "Exception" (identification and declaration) is an important
concern for designer. Both System exceptions and application exceptions
needs to be carefully designed in CORBA environment.

This ensures that while a designer is designing the core functionality of
the application, he is forced to design Exceptions that could potentially
be thrown by the application code. Exception handling is an designers
problem and should be left on the mercy of developer.

regards,
Shashank


> Now, is there a design pattern, methodology - even a name for this
> idea ? Is it new, can anyone help ? Even if only to confirm that I'm
> not barking up the wrong tree. If patterns isn't the place for this,
> is there anywhere better ?