RE: Exception Handling Opinion 2004-12-14 - By Tim Weaver
Excellent discussion all.
I chose the inventory example because it is what I consider to be a
"well known" problem. Any site that sells something has inventory and
has to check it prior to accepting an order. A lot of sites simply
accept the order regardless of inventory and notify the user of back
order, etc. What is interesting about this problem is that it is so
common, but as this discussion shows, there are a great many different
ways to handle it.
On Mon, 13 Dec 2004 17:53:56 -0800 (PST), Philip Nelson
<panmanphil@(protected)> wrote:
>
> --- Robert Hanson <rhanson@(protected)> wrote:
> > I'm not sure what you're trying to accomplish here.
> >
> > If your business component has a rule, and the data provided is
> > inappropriate, then it is acceptable to throw an exception. The consumer
> > of the business logic should expect the exception and catch it. What they
> > decide to do with it is up to them. If you want the consumer of the
> > exception to change the message, well then you should document what the
> > exception is and what you expect the consumer to do, and leave it at that.
>
> I guess I disagree with that statement in theory even if in practice it's
often
> what happens. A well behaved object should only blow up when it can't be in a
> consistent state based on the input received. If a caller of one of my objects
> passes a null or inappropriate type to a method, my ideal object would somehow
> pass back a message telling the caller nicely what it did wrong. That is where
> a delegate might make more sense. Another approach I have often used is a
> "ProcessLog" that allows the object to log the problem, protect it's internal
> state and continue on. This is especially useful when processing streams of
> data and you need to continue on.
>
> Very often though, an exception does get thrown when an object can't handle
> something. In that case, a well behaved object should add it's own information
> to the stack trace to help the system determine what went wrong. These
> partially handled exceptions can be associated with user messages by typing
> them to something that an upstream error handler can interpret.
>
> Finally, there are those cases where there was no idea what went wrong in the
> code. I agree with others that say this should just get bubbled up unhandled
> until the top level error handler logs the stack trace and gives a general
> error message.
>
> =====
> Philip - http://blogs.xcskiwinn.org/panmanphil
> "There's a difference between righteous anger and just being crabby" - Barbara
>
> Need SQL Advice? http://sqladvice.com
> Need RegEx Advice? http://regexadvice.com
> Need XML Advice? http://xmladvice.com
>
Need SQL Advice? http://sqladvice.com
Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com
|
|
