Re: Exception handling in multitier applications

Hi Seref,

One thing that I failed to mention is that many times, our
web services may
be called from more than one app.  And different apps need
to handle errors
in possibly different ways.

If you have a layer or layers that will be used by one
program, then it may
make sense to handle more of the errors in the one of the
layers.  I guess
it also depends on if the calling/front-end program consists
of a GUI or is
just some sort of console app.

In the end, I guess it just depends.  LOL.

Also, I do use the data application block, validation block,
and some of the
other blocks from the Enterprise Library.  It's good stuff.

Bobby

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On Behalf Of Seref
Arikan
Sent: Tuesday, July 01, 2008 12:34 PM
To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Exception handling in
multitier applications

Hi Bobby,
I guess letting the layers to bubble the error up is a less
complex way than
handling them at the layer they originated. When you start
handling them in
various layers, you find yourself in a position where you
have to code for
different combinations of errors in various layers. I
bubbling up as much as
possible is an option, though it might push a little bit
more code to front
ends. Thanks for your response

Cheers
Seref

On Tue, Jul 1, 2008 at 3:32 AM, Bobby Heid <bheidsc.rr.com> wrote:

> Hi Seref,
>
> I do not have any resources for you, but this is the
way we handle it at
> work.
>
> For a given app, we may have the application, service
agent (used to call
> into the web service), one or more web services, and
usually one data
layer
> to go with each web service that needs one.
>
> We let the data layer exceptions bubble up to the web
service layer, where
> we log the error and any other information that we want
and then re-throw
> the error.  The service agent layer simply bubbles up
the exception.
> Finally the application itself traps the error and
handles it the way it
> sees fit.
>
> There are times where in some of the layers, we may
trap certain errors
> that
> can be handled in a logical way, but in general we do
as above.  We try to
> create reusable web service/data layers so that
multiple apps can use
them.
>
> Bobby
>
> -----Original Message-----
> From: Discussion of advanced .NET topics.
> [mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On
Behalf Of Seref Arikan
> Sent: Thursday, June 26, 2008 5:41 AM
> To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
> Subject: [ADVANCED-DOTNET] Exception handling in
multitier applications
>
> Hi,
> I'd like to get your opinions, and if possible pointers
to resources for
> exception handling in multitier .net applications. When
you have a usual
> multitier app, you usually have a db access layer like
a generated ORM
> classes, web services exposing them, and clients (web
and desktop) that
> consume these services.
> At the moment I have a few apps that I'm maintaining,
and some web pages
> and
> windows forms are constructed by calls to various web
services, and later
> combining their outputs. However, there are a lot
things that can go
wrong,
> like a syntactically correct input being rejected by a
back end service,
> which requires adjustments in the user interface like
disabling  various
> parts of the screen etc.
> I've come to realize that error handling code scattered
around layers is
> the
> most ugly part of all software that I write.
> We have a lot of best practices and design options but
resources about
them
> seem to cover mostly the cases where things go as
expected. A consistent
> approach to handling errors would be really nice, for
what I have right
now
> is just results of my own experience, and I believe in
learning from
> other's
> mistakes and best practices.
> Do you have any resources that I can benefit from? Any
error-handling
> patterns? For example how and where do you log and
report errors in a web
> based app? I've realized that error handling aspects
tend to cross cut
> multiple layers sometimes, and writing code to cover
these aspects leads
to
> high coupling between layers. After spending a great
amount of effort for
> low coupling, this is not nice!
> I'd be more than happy to hear your thoughts and
suggestions
>
> Regards
> Seref
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>

===================================
This list is hosted by DevelopMentorR  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com


===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Hi Bobby,

I guess the app blocks will be a valuable resource. I'll be
refactoring an
existing app next week just to play with various exception
handling
approaches, to see which one produces cleaner and more
maintainable results.
If I can find the time to do it, I'll post in my blog.

Cheers

Seref

On Thu, Jul 17, 2008 at 5:53 AM, Bobby Heid <bheidsc.rr.com> wrote:

> Hi Seref,
>
> One thing that I failed to mention is that many times,
our web services may
> be called from more than one app.  And different apps
need to handle errors
> in possibly different ways.
>
> If you have a layer or layers that will be used by one
program, then it may
> make sense to handle more of the errors in the one of
the layers.  I guess
> it also depends on if the calling/front-end program
consists of a GUI or is
> just some sort of console app.
>
> In the end, I guess it just depends.  LOL.
>
> Also, I do use the data application block, validation
block, and some of
> the
> other blocks from the Enterprise Library.  It's good
stuff.
>
> Bobby
>
> -----Original Message-----
> From: Discussion of advanced .NET topics.
> [mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On
Behalf Of Seref Arikan
> Sent: Tuesday, July 01, 2008 12:34 PM
> To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
> Subject: Re: [ADVANCED-DOTNET] Exception handling in
multitier applications
>
> Hi Bobby,
> I guess letting the layers to bubble the error up is a
less complex way
> than
> handling them at the layer they originated. When you
start handling them in
> various layers, you find yourself in a position where
you have to code for
> different combinations of errors in various layers. I
bubbling up as much
> as
> possible is an option, though it might push a little
bit more code to front
> ends. Thanks for your response
>
> Cheers
> Seref
>
> On Tue, Jul 1, 2008 at 3:32 AM, Bobby Heid
<bheidsc.rr.com> wrote:
>
> > Hi Seref,
> >
> > I do not have any resources for you, but this is
the way we handle it at
> > work.
> >
> > For a given app, we may have the application,
service agent (used to call
> > into the web service), one or more web services,
and usually one data
> layer
> > to go with each web service that needs one.
> >
> > We let the data layer exceptions bubble up to the
web service layer,
> where
> > we log the error and any other information that we
want and then re-throw
> > the error.  The service agent layer simply bubbles
up the exception.
> > Finally the application itself traps the error and
handles it the way it
> > sees fit.
> >
> > There are times where in some of the layers, we
may trap certain errors
> > that
> > can be handled in a logical way, but in general we
do as above.  We try
> to
> > create reusable web service/data layers so that
multiple apps can use
> them.
> >
> > Bobby
> >
> > -----Original Message-----
> > From: Discussion of advanced .NET topics.
> > [mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On
Behalf Of Seref Arikan
> > Sent: Thursday, June 26, 2008 5:41 AM
> > To: ADVANCED-DOTNETDISCUSS.DEVELOP.COM
> > Subject: [ADVANCED-DOTNET] Exception handling in
multitier applications
> >
> > Hi,
> > I'd like to get your opinions, and if possible
pointers to resources for
> > exception handling in multitier .net applications.
When you have a usual
> > multitier app, you usually have a db access layer
like a generated ORM
> > classes, web services exposing them, and clients
(web and desktop) that
> > consume these services.
> > At the moment I have a few apps that I'm
maintaining, and some web pages
> > and
> > windows forms are constructed by calls to various
web services, and later
> > combining their outputs. However, there are a lot
things that can go
> wrong,
> > like a syntactically correct input being rejected
by a back end service,
> > which requires adjustments in the user interface
like disabling  various
> > parts of the screen etc.
> > I've come to realize that error handling code
scattered around layers is
> > the
> > most ugly part of all software that I write.
> > We have a lot of best practices and design options
but resources about
> them
> > seem to cover mostly the cases where things go as
expected. A consistent
> > approach to handling errors would be really nice,
for what I have right
> now
> > is just results of my own experience, and I
believe in learning from
> > other's
> > mistakes and best practices.
> > Do you have any resources that I can benefit from?
Any error-handling
> > patterns? For example how and where do you log and
report errors in a web
> > based app? I've realized that error handling
aspects tend to cross cut
> > multiple layers sometimes, and writing code to
cover these aspects leads
> to
> > high coupling between layers. After spending a
great amount of effort for
> > low coupling, this is not nice!
> > I'd be more than happy to hear your thoughts and
suggestions
> >
> > Regards
> > Seref
> >
> > ===================================
> > This list is hosted by DevelopMentor(R)  http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com

> >
>
> ===================================
> This list is hosted by DevelopMentorR  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com