exceptions to the rule

[rodchar]

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

 

[Peter Duniho]

[...]
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

 

[Tom P.]

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)? Butif
i handle it in the business layer how will the different user interfaces know
an error has occurred?

thanks,
rodchar

You pretty much answered your own question: If you catch an exception
and "swallow" it how will the interface know? It won't so you've
screwed your UI.

One of the currently prevailing outlooks is unless there is something
you can do about or with the exception let it go up. You can then
place error trapping and logging code around the UI and it will log
any errors you get. Now you don't have to trap EVERY error your code
throws. Besides, you probably want to know that something in your code
didn't work the way you wanted it to.

Tom P.

 

[Registered User]

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.

 

[rodchar]

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.

[...]
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

 

[rodchar]

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

 

[Peter Duniho]

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.

I don't know. I don't know anything about your program, nor how you are
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

 

[Peter Duniho]

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.

Seems like a fine idea.

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
handled in the ui

Why does your UI have anything to do with creating an Excel file? That
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
this class. my concern here is that there will be an uncaught exception.

Why? What exception would be uncaught?

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

 

[Registered User]

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.

I assume the file is created by the business layer. How is the UI
informed of the file's name and path?

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.

Your question seems to be what is the best way to notify the UI that
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.

 

[rodchar]

thanks everyone for the great feedback,
rod.