Error Handling in a DAL

[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.GetStoredPro cCommand(sqlCom mand);

try
{
db.ExecuteNonQu ery(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.Ins ert();
if (ErrorText.ToSt ring() != "success")
{
Response.Write (ErrorText);
}

[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

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Garth Wells" <no****@nowhere .com> wrote in message
news:OD******** ******@TK2MSFTN GP10.phx.gbl...

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.GetStoredPro cCommand(sqlCom mand);

try
{
db.ExecuteNonQu ery(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.Ins ert();
if (ErrorText.ToSt ring() != "success")
{
Response.Write (ErrorText);
}

[Mark Rae]

"Garth Wells" <no****@nowhere .com> wrote in message
news:OD******** ******@TK2MSFTN GP10.phx.gbl...

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]

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:OL******** *****@TK2MSFTNG P15.phx.gbl...

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

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Garth Wells" <no****@nowhere .com> wrote in message
news:OD******** ******@TK2MSFTN GP10.phx.gbl...

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.GetStoredPro cCommand(sqlCom mand);

try
{
db.ExecuteNonQu ery(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.Ins ert();
if (ErrorText.ToSt ring() != "success")
{
Response.Write (ErrorText);
}

[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/
"Garth Wells" <no****@nowhere .com> wrote in message
news:eB******** ******@TK2MSFTN GP12.phx.gbl...

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:OL******** *****@TK2MSFTNG P15.phx.gbl...

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

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Garth Wells" <no****@nowhere .com> wrote in message
news:OD******** ******@TK2MSFTN GP10.phx.gbl...

> 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.GetStoredPro cCommand(sqlCom mand);
>
> try
> {
> db.ExecuteNonQu ery(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.Ins ert();
> if (ErrorText.ToSt ring() != "success")
> {
> Response.Write (ErrorText);
> }
>
>

[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...
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:uX******** ******@TK2MSFTN GP11.phx.gbl...

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/
"Garth Wells" <no****@nowhere .com> wrote in message
news:eB******** ******@TK2MSFTN GP12.phx.gbl...

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:OL******** *****@TK2MSFTNG P15.phx.gbl...

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

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Garth Wells" <no****@nowhere .com> wrote in message
news:OD******** ******@TK2MSFTN GP10.phx.gbl...
> 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.GetStoredPro cCommand(sqlCom mand);
>
> try
> {
> db.ExecuteNonQu ery(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.Ins ert();
> if (ErrorText.ToSt ring() != "success")
> {
> Response.Write (ErrorText);
> }
>
>

[Karl Seguin [MVP]]

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

Karl
--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Garth Wells" <no****@nowhere .com> wrote in message
news:eQ******** *****@tk2msftng p13.phx.gbl...

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...
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net>
wrote in message news:uX******** ******@TK2MSFTN GP11.phx.gbl...

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/
"Garth Wells" <no****@nowhere .com> wrote in message
news:eB******** ******@TK2MSFTN GP12.phx.gbl...

> 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:OL******** *****@TK2MSFTNG P15.phx.gbl...
>> 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
>>
>> --
>> http://www.openmymind.net/
>> http://www.fuelindustries.com/
>>
>>
>> "Garth Wells" <no****@nowhere .com> wrote in message
>> news:OD******** ******@TK2MSFTN GP10.phx.gbl...
>> > 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.GetStoredPro cCommand(sqlCom mand);
>> >
>> > try
>> > {
>> > db.ExecuteNonQu ery(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.Ins ert();
>> > if (ErrorText.ToSt ring() != "success")
>> > {
>> > Response.Write (ErrorText);
>> > }
>> >
>> >
>>
>>
>
>

[Garth Wells]

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

"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:#S******** ******@TK2MSFTN GP15.phx.gbl...

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

Karl
--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Garth Wells" <no****@nowhere .com> wrote in message
news:eQ******** *****@tk2msftng p13.phx.gbl...

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...
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net>
wrote in message news:uX******** ******@TK2MSFTN GP11.phx.gbl...

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/
"Garth Wells" <no****@nowhere .com> wrote in message
news:eB******** ******@TK2MSFTN GP12.phx.gbl...
> 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:OL******** *****@TK2MSFTNG P15.phx.gbl...
>> 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
>>
>> --
>> http://www.openmymind.net/
>> http://www.fuelindustries.com/
>>
>>
>> "Garth Wells" <no****@nowhere .com> wrote in message
>> news:OD******** ******@TK2MSFTN GP10.phx.gbl...
>> > 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.GetStoredPro cCommand(sqlCom mand);
>> >
>> > try
>> > {
>> > db.ExecuteNonQu ery(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.Ins ert();
>> > if (ErrorText.ToSt ring() != "success")
>> > {
>> > Response.Write (ErrorText);
>> > }
>> >
>> >
>>
>>
>
>