Error Handling in a DAL

[Karl Seguin [MVP]]

Your error handling isn't very good...you are CATCHING the error but not
HANDLING it...instead you are swallowing any possible error.

90% of the time you can't really handle an error, all you can do is clean up
after yourself, that's why the using keyword exists. The proper way to do
this is:

using (connection...){
using(command){
using (datareader{
execute
}
}
}

and then in your global.asax's OnError, catch any unhandled error, log it
(if desired) and display a frienly error message.

Karl

 

[Mark Rae]

I'm trying to create a DAL and am wondering what's the proper way to
handle errors in this Insert method.

It doesn't really look as if you're handling the error(s) at all - other
than catching them, what are you actually doing about them...? What are you
doing to prevent unclosed connections? How are you destroying any object
variables? Consider creating objects with the "using" reserved word, or
implementing a finally{...} clause...

 

[Garth Wells]

I'm trying to create a DAL and am wondering what's the proper way to
handle errors in this Insert method.


public string Insert()
{
Database db = DatabaseFactory.CreateDatabase();
string sqlCommand = "pr_testx";
DbCommand dbCommand = db.GetStoredProcCommand(sqlCommand);

try
{
db.ExecuteNonQuery(dbCommand);
}
catch (SqlException SqlExc)
{
return " ERROR:" + SqlExc.Message + "<br>";
}
catch (Exception ex)
{
return " ERROR:" + ex.Message + "<br>";
}

return "success";
}


I call it with the following and it works (it's intentionally generating a proc
not found error), but I'm not sure this is the best way to implement error
handling.

string ErrorText;
ErrorText = saleProduct.Insert();
if (ErrorText.ToString() != "success")
{
Response.Write (ErrorText);
}

 

[Garth Wells]

Thanks for the feedback. Can you point me to a full example of this on the
web? I didn't find any that used this exact approach.

Thanks

 

[Karl Seguin [MVP]]

I don't know of any off-hand. It isn't really an "approach", it's

There's a great interview with Anders (distinguished engineer, guy in charge
of c#) about checked exceptions.

http://www.artima.com/intv/handcuffs2.html

I liked you to page 2, you'll find the last 3 sections where he talks
informative, but most relevant:

"Error handling you put somewhere else. Surely in any kind of event-driven
application like any kind of modern UI, you typically put an exception
handler around your main message pump, and you just handle exceptions as
they fall out that way. But you make sure you protect yourself all the way
out by deallocating any resources you've grabbed, and so forth. You clean up
after yourself, so you're always in a consistent state. You don't want a
program where in 100 different places you handle exceptions and pop up error
dialogs. What if you want to change the way you put up that dialog box?
That's just terrible. The exception handling should be centralized, and you
should just protect yourself as the exceptions propagate out to the
handler."


Karl
--
http://www.openmymind.net/
http://www.fuelindustries.com/

Thanks for the feedback. Can you point me to a full example of this on the
web? I didn't find any that used this exact approach.

Thanks


"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net>
wrote in message news:[email protected]...

 

[Karl Seguin [MVP]]

Can you provide me with a specific link? I'll see what i can do

Karl

 

[Garth Wells]

Thanks

Interesting article...too bad he didn't tell the people who write the MSDN
examples about this approach. Found this in the: "How to: Handle
Application-Level Errors" topic.

"It is preferable to use Try/Catch blocks around any code that is subject to
errors rather than rely on a global error handler."

They sure do make it hard to adopt a best practice...

 

[Garth Wells]

http://msdn2.microsoft.com/en-us/library/24395wz3.aspx