Exception handling

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

In my enterprise application I'd like my DataAccess layer to be responsible
for handling all database error situations and to basically throw custom
exceptions according to whether db connection is ok or not, that is,
cDBDownException if ok or cDBException if not ok. These two exceptions would
provide all information about the original cause etc.

1. Is this a wise exception handling policy?

2. We use both Oracle and SQL Server. Which exceptions do I catch to
ascertain that we've lost contact with the db?

Kind regards.
 
Hi,

Raising exceptions is a very expensive operation, so you should raise them
on "exceptional" occasions, never raise an exception to say "yes, is
working", only if you receive something unexpected.

If you use the .NET providers for SQL Server and Oracle you have your custom
excpetions like SQLException, or if you are not using the .net providers use
the generic one Exception.

Again, is good to have them but not abuse them :)

Cheers
Salva
 
Salvador said:
Raising exceptions is a very expensive operation, so you should raise them
on "exceptional" occasions, never raise an exception to say "yes, is
working", only if you receive something unexpected.
Click to expand...

When you say "very expensive", just how expensive would you guess they
are (without testing)? How many would you guess your computer could
throw (not running in a debugger) per second? After guessing, give it a
try...

In my experience, most developers have a vastly exaggerated idea of how
expensive it is to raise an exception. While they should certainly only
be raised when appropriate, that's more for readability reasons than
performance reasons. Raising an exception to say that something is okay
is unintuitive and would therefore damage readability - something far
more important than performance for most pieces of code. (Most pieces
of code aren't really significant in the overall performance. There
tends to be a bottleneck in a small part of your code, sometimes out of
your control.)

I don't remember ever seeing a single performance problem which was
actually due to overusing exceptions. I've seen various bugs due to
people trying to avoid using exceptions because they thought they were
expensive, and therefore used return values which sometimes weren't
checked...

The only time exceptions are likely to cause a performance problem is
if they're thrown within a loop which doesn't do much else.
 
Raising exceptions is a very expensive operation, so you should raise them
on "exceptional" occasions, never raise an exception to say "yes, is
working", only if you receive something unexpected.
Click to expand...

That's how I first read what the OP wrote, but I don't think that's what
he means. I think he's saying that he wants to throw one type of custom
exception for failure to connect to the database and another for all
other errors.
 
in that case, that design will be hard to sell. the custom exceptions should
mirror the already supported exceptions - argumentnullexception,
methodnotimplemented exception etc. With this approach, you don't lump all
other exceptions into a category because it isn't logically accurate. try
grouping exceptions logically and then defining a type for these groupings

--
Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc
 
Alvin Bruney said:
in that case, that design will be hard to sell. the custom exceptions
should mirror the already supported exceptions - argumentnullexception,
methodnotimplemented exception etc. With this approach, you don't lump all
other exceptions into a category because it isn't logically accurate. try
grouping exceptions logically and then defining a type for these groupings
Click to expand...

I'm generally not a big fan of custom exceptions especially if the exception
is propagated across a machine boundary. This increases the complexity of
the packaging and deployment of assemblies as the exception cannot be
decoded and caught or rethrown on the client unless it has an assembly with
a definition of the custom exception available. I prefer to map it to
exception types defined in one of the BCL's. I think custom exceptions are
far more useful within the scope of the defining assembly.

Dave
 
Back
Top