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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] On Behalf Of Seref Arikan > Sent: Tuesday, July 01, 2008 12:34 PM > To: ADVANCED-DOTNET@DISCUSS.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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] On Behalf Of Seref Arikan > > Sent: Thursday, June 26, 2008 5:41 AM > > To: ADVANCED-DOTNET@DISCUSS.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
