|
ms
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
exceptions to the rulehey all,
alright, so i have the basic 3-tier (logical) application and down in the data layer i'm throwing an exception if 0 records are returned from the database. i have a try catch in the user interface (happens to be the console) and that works fine. well, let's say i wanted to use my business layer in a web app so i guess i'll put a try catch there as well? or should i handle this in the business layer so i won't have to write multiple try catches? how is this normally handled (no pun intended)? But if i handle it in the business layer how will the different user interfaces know an error has occurred? thanks, rodchar On Wed, 01 Jul 2009 11:10:01 -0700, rodchar
<rodc***@discussions.microsoft.com> wrote: > [...] If you handle it in the business layer, why does the UI need to know an > or should i handle this in the business layer so i won't have to write > multiple try catches? how is this normally handled (no pun intended)? > But if > i handle it in the business layer how will the different user interfaces > know > an error has occurred? error occurred? Generally speaking, you handle the exception where you can actually do something useful with it. In C#, we have "finally" for dealing with cleanup even if an exception occurs, so there's no need to actually "catch" an exception unless you're going to handle it (recover from it). In some cases, you can't distinguish between an exception you can handle and one you can't until you actually catch and inspect the specific exception. But this isn't very common, and you'd basically treat that the same in the sense that you'd simply rethrow the exception if you can't recover from it. Pete Let's say the user entered a key and the application had to goto the
database but it returned no records. i want the user to know this kind of information right. Show quoteHide quote "Peter Duniho" wrote: > On Wed, 01 Jul 2009 11:10:01 -0700, rodchar > <rodc***@discussions.microsoft.com> wrote: > > > [...] > > or should i handle this in the business layer so i won't have to write > > multiple try catches? how is this normally handled (no pun intended)? > > But if > > i handle it in the business layer how will the different user interfaces > > know > > an error has occurred? > > If you handle it in the business layer, why does the UI need to know an > error occurred? > > Generally speaking, you handle the exception where you can actually do > something useful with it. In C#, we have "finally" for dealing with > cleanup even if an exception occurs, so there's no need to actually > "catch" an exception unless you're going to handle it (recover from it). > > In some cases, you can't distinguish between an exception you can handle > and one you can't until you actually catch and inspect the specific > exception. But this isn't very common, and you'd basically treat that the > same in the sense that you'd simply rethrow the exception if you can't > recover from it. > > Pete > On Wed, 01 Jul 2009 12:06:01 -0700, rodchar
<rodc***@discussions.microsoft.com> wrote: > Let's say the user entered a key and the application had to goto the I don't know. I don't know anything about your program, nor how you are > database but it returned no records. i want the user to know this kind of > information right. accessing the database (in many scenarios, finding no records simply means you get an empty collection, not an error). But, the point remains the same. If in your business layer you have no way to recover from the error, there's not really any point in catching it in that layer. Pete On Wed, 1 Jul 2009 11:10:01 -0700, rodchar
<rodc***@discussions.microsoft.com> wrote: >hey all, At this level is the fact that zero records are found really an error?> >alright, so i have the basic 3-tier (logical) application and down in the >data layer i'm throwing an exception if 0 records are returned from the >database. > >i have a try catch in the user interface (happens to be the console) This layer seems more appropriate to determine what happens when zeroand >that works fine. well, let's say i wanted to use my business layer in a web >app so i guess i'll put a try catch there as well? > records are found. Depending upon business rules zero records found may be an error or zero may just be the size of the resultset. >or should i handle this in the business layer so i won't have to write Consider an eCommerce site which makes use of a shopping cart. If the>multiple try catches? how is this normally handled (no pun intended)? But if >i handle it in the business layer how will the different user interfaces know >an error has occurred? user looks in the shopping cart and no items are found, is it an error or is it just a statement of fact that the shopping cart contains no items? In the latter both the DAL and BL can be agnostic and let the UI handle the condition that no records were found. Once again it all depends upon the business rules specific to the application. The real error may be in the assumption that the resultset will always contain one or more records. regards A.G. good points,
ok so let's say zero records are aceeptable. the application creates an excel file with the records from the db. i don't want it to create the excel file if there are no records. would this be considered an exception? if i leave this as an exception to be handled in the ui and let's say later down the road someone else wants to use this class. my concern here is that there will be an uncaught exception. sorry if i keep missing the point :( Show quoteHide quote "Registered User" wrote: > On Wed, 1 Jul 2009 11:10:01 -0700, rodchar > <rodc***@discussions.microsoft.com> wrote: > > >hey all, > > > >alright, so i have the basic 3-tier (logical) application and down in the > >data layer i'm throwing an exception if 0 records are returned from the > >database. > > > At this level is the fact that zero records are found really an error? > >i have a try catch in the user interface (happens to be the console) > and > >that works fine. well, let's say i wanted to use my business layer in a web > >app so i guess i'll put a try catch there as well? > > > This layer seems more appropriate to determine what happens when zero > records are found. Depending upon business rules zero records found > may be an error or zero may just be the size of the resultset. > > >or should i handle this in the business layer so i won't have to write > >multiple try catches? how is this normally handled (no pun intended)? But if > >i handle it in the business layer how will the different user interfaces know > >an error has occurred? > Consider an eCommerce site which makes use of a shopping cart. If the > user looks in the shopping cart and no items are found, is it an error > or is it just a statement of fact that the shopping cart contains no > items? In the latter both the DAL and BL can be agnostic and let the > UI handle the condition that no records were found. > > Once again it all depends upon the business rules specific to the > application. The real error may be in the assumption that the > resultset will always contain one or more records. > > regards > A.G. > On Wed, 01 Jul 2009 12:33:01 -0700, rodchar
<rodc***@discussions.microsoft.com> wrote: > good points, Seems like a fine idea.> > ok so let's say zero records are aceeptable. the application creates an > excel file with the records from the db. i don't want it to create the > excel > file if there are no records. > would this be considered an exception? Is there anything in that scenario in which an exception is thrown? If not, then no...it wouldn't be "considered" an exception. In this context, exception handling is only about actuall exceptions thrown using the "throw" statement. If you're not talking about that, then you're simply talking about general design issues within your own code. And the specific ways to deal with those issues depends on how you want your code to behave. There's not any hard-and-fast rule that covers that. > if i leave this as an exception to be Why does your UI have anything to do with creating an Excel file? That > handled in the ui doesn't sound like a UI thing to me. UI is about how your program interacts with the user, not how it interacts with the file system or other installed applications. > and let's say later down the road someone else wants to use Why? What exception would be uncaught?> this class. my concern here is that there will be an uncaught exception. > sorry if i keep missing the point :( Until you provide something more specific, I'm not sure there's a point to be missed. Your question is vague, and so you get vague answers. I've stated the general rule, and there's nothing about your question that would offer specific enough information to know how to apply that rule. Pete On Wed, 1 Jul 2009 12:33:01 -0700, rodchar
<rodc***@discussions.microsoft.com> wrote: >good points, I assume the file is created by the business layer. How is the UI> >ok so let's say zero records are aceeptable. the application creates an >excel file with the records from the db. i don't want it to create the excel >file if there are no records. > informed of the file's name and path? >would this be considered an exception? if i leave this as an exception to be Your question seems to be what is the best way to notify the UI that>handled in the ui and let's say later down the road someone else wants to use >this class. my concern here is that there will be an uncaught exception. > the resultset is empty and that an Excel file was not created. This situation might be worthy of throwing an exception. Then again the BL might pass an empty string to the UI instead of the file's name and path or ... well there are many ways it might be done. I think the key is to document the type's behavior. When records are found this happens while this something else happens when no records are found. Anyone using the using the type needs to handle each situation accordingly whether an exception is thrown or not. >sorry if i keep missing the point :( You didn't miss the point., you're trying to think things through and> determine the best way to accomplish the task. Too many people concentrate on what happens when everything goes right and pay less attention to the negative case. regards A.G. Show quoteHide quote > > > > >"Registered User" wrote: > >> On Wed, 1 Jul 2009 11:10:01 -0700, rodchar >> <rodc***@discussions.microsoft.com> wrote: >> >> >hey all, >> > >> >alright, so i have the basic 3-tier (logical) application and down in the >> >data layer i'm throwing an exception if 0 records are returned from the >> >database. >> > >> At this level is the fact that zero records are found really an error? >> >i have a try catch in the user interface (happens to be the console) >> and >> >that works fine. well, let's say i wanted to use my business layer in a web >> >app so i guess i'll put a try catch there as well? >> > >> This layer seems more appropriate to determine what happens when zero >> records are found. Depending upon business rules zero records found >> may be an error or zero may just be the size of the resultset. >> >> >or should i handle this in the business layer so i won't have to write >> >multiple try catches? how is this normally handled (no pun intended)? But if >> >i handle it in the business layer how will the different user interfaces know >> >an error has occurred? >> Consider an eCommerce site which makes use of a shopping cart. If the >> user looks in the shopping cart and no items are found, is it an error >> or is it just a statement of fact that the shopping cart contains no >> items? In the latter both the DAL and BL can be agnostic and let the >> UI handle the condition that no records were found. >> >> Once again it all depends upon the business rules specific to the >> application. The real error may be in the assumption that the >> resultset will always contain one or more records. >> >> regards >> A.G. >> thanks everyone for the great feedback,
rod. Show quoteHide quote "rodchar" wrote: > hey all, > > alright, so i have the basic 3-tier (logical) application and down in the > data layer i'm throwing an exception if 0 records are returned from the > database. > > i have a try catch in the user interface (happens to be the console) and > that works fine. well, let's say i wanted to use my business layer in a web > app so i guess i'll put a try catch there as well? > > or should i handle this in the business layer so i won't have to write > multiple try catches? how is this normally handled (no pun intended)? But if > i handle it in the business layer how will the different user interfaces know > an error has occurred? > > thanks, > rodchar  
Other interesting topics
set location of Form2 based on Location of Form1?
OT: missing posts Linq to Sql Exception Specified cast is not valid getting to know c# check console args A question on naming schemes - when frequent collissions with the BCLs are present C# Export Excel to client side Application configuration settings - Do I make global? How to find out what the server name is? show and hide and iframe from code behind not using button click g |
|||||||||||||||||||||||
