Is this structure good for methods?

[Steven Blair]

Looking for some opinions on the structure of this method, namely the
way errors are handled and reported:

http://pastebin.com/711366

My view is this is quite a good method of trapping and moving through a
flow of data.

Anyone suggest a better way?

Steven

*** Sent via Developersdex http://www.developersdex.com ***

[Barry Kelly]

Pa********@gmai l.com wrote:

In fact, one last hijack, if people will indulge it, with a more
concrete example.

I have an ecommerce application, www.WidgetStore.com with a whole bunch
of stored procs to CRUD, each of which returns error codes to denote
success or reasons for failure.

J Random User tries to add a Widget to his shopping cart, but while he
was making coffee, some other user bought the last one. The proc for
updating carts and stock quantities fails because business logic is
violated (you can only add a product to your cart if it is in stock).

If you have transactional semantics for your business logic, (for
example, you can only add stuff to your basket if it is in stock, and
the two go together relatively atomically), you can take advantage of
exceptions and properly structured try/catch blocks to roll-back any
changes.

The try/catch blocks would look somewhat like:

---8<---
// do stuff A
try
{
// do stuff B
}
catch
{
// roll back stuff A
throw;
}
--->8---

Whether this would make your business code simpler, I don't know.

-- Barry