By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,918 Members | 1,923 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,918 IT Pros & Developers. It's quick & easy.

How to get rid of Bad Coding Habits /// return status

P: n/a


Does anyone have any good articles on Exception Handing in DotNet.
As a "get rid of the API mode of knowing if something worked, we're not in
VB6 land anymore Dorothy".
I have a few people at work who keep writing code like below.
public string UpdateEmployee
{
string returnStatus = string.Empty;
try {
Database db = this.GetDatabase();
DbCommand dbCommand = db.GetStoredProcCommand("dbo.[uspAAAAAAAAAAAAAA]");
(dbCommand);

db.ExecuteNonQuery(dbCommand);
}

catch (Exception ex) {
sStatus = "ERROR updating Examiner table: " + ex.Message;
}
return returnStatus;

}
and I need some reference(s) to put a stop to this mess.
At least with API, you checked for = or != to 0.

err.Number
case --020303000003003
msg = "The blah blah blah failed"

Those were good times.

Any good articles are appreciated (esp if the directly tackle this
situation )



Apr 25 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
sloan <sl***@ipass.netwrote:
Does anyone have any good articles on Exception Handing in DotNet.
As a "get rid of the API mode of knowing if something worked, we're not in
VB6 land anymore Dorothy".
http://blogs.msdn.com/kcwalina/archi...16/396787.aspx

is a very good set of guidelines on when to use exceptions and when not
to, IMO. There are exceptions to the guidelines, of course...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 25 '07 #2

P: n/a
Bingo!

Thanks Jon.

Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks.

is #1 on his list. Perfect!

...
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*******************@msnews.microsoft.com...
sloan <sl***@ipass.netwrote:
Does anyone have any good articles on Exception Handing in DotNet.
As a "get rid of the API mode of knowing if something worked, we're not
in
VB6 land anymore Dorothy".

http://blogs.msdn.com/kcwalina/archi...16/396787.aspx

is a very good set of guidelines on when to use exceptions and when not
to, IMO. There are exceptions to the guidelines, of course...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Apr 26 '07 #3

P: n/a
Hehe.
You have to be patient, Sloan.
Explain to them that the caller of this method should wrap their call in a
try / catch block and be prepared to accept the fact that they may get back
an exception.

And just explain why they should not populate some return "string" with the
exception message property and instead, throw the actual exception itself.

-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"sloan" wrote:
>

Does anyone have any good articles on Exception Handing in DotNet.
As a "get rid of the API mode of knowing if something worked, we're not in
VB6 land anymore Dorothy".
I have a few people at work who keep writing code like below.
public string UpdateEmployee
{
string returnStatus = string.Empty;
try {
Database db = this.GetDatabase();
DbCommand dbCommand = db.GetStoredProcCommand("dbo.[uspAAAAAAAAAAAAAA]");
(dbCommand);

db.ExecuteNonQuery(dbCommand);
}

catch (Exception ex) {
sStatus = "ERROR updating Examiner table: " + ex.Message;
}
return returnStatus;

}
and I need some reference(s) to put a stop to this mess.
At least with API, you checked for = or != to 0.

err.Number
case --020303000003003
msg = "The blah blah blah failed"

Those were good times.

Any good articles are appreciated (esp if the directly tackle this
situation )



Apr 26 '07 #4

P: n/a
Dude,

I've been patient. I've tried examples, making KB's, going to their desk to
help.
Asking, being nice. I'm about as helpful as I can be when it comes to
trying to help.
I think they think because I work with them, that they think I don't know
what I'm talking about sometimes.

I need something that is more "official" then my advice and home made KB's I
guess. Thus my post.

Anyway, thanks for the encouragement.

..............

Patience is definately a lost art these days.


"Peter Bromberg [C# MVP]" <pb*******@yahoo.yabbadabbadoo.comwrote in
message news:60**********************************@microsof t.com...
Hehe.
You have to be patient, Sloan.
Explain to them that the caller of this method should wrap their call in a
try / catch block and be prepared to accept the fact that they may get
back
an exception.

And just explain why they should not populate some return "string" with
the
exception message property and instead, throw the actual exception itself.

-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"sloan" wrote:


Does anyone have any good articles on Exception Handing in DotNet.
As a "get rid of the API mode of knowing if something worked, we're not
in
VB6 land anymore Dorothy".
I have a few people at work who keep writing code like below.
public string UpdateEmployee
{
string returnStatus = string.Empty;
try {
Database db = this.GetDatabase();
DbCommand dbCommand =
db.GetStoredProcCommand("dbo.[uspAAAAAAAAAAAAAA]");
(dbCommand);

db.ExecuteNonQuery(dbCommand);
}

catch (Exception ex) {
sStatus = "ERROR updating Examiner table: " + ex.Message;
}
return returnStatus;

}
and I need some reference(s) to put a stop to this mess.
At least with API, you checked for = or != to 0.

err.Number
case --020303000003003
msg = "The blah blah blah failed"

Those were good times.

Any good articles are appreciated (esp if the directly tackle this
situation )



Apr 26 '07 #5

P: n/a
sloan,

One thing though, be VERY aware of this recommendation:

Do not use exceptions for normal flow of control

Basically, for logical errors (validating business logic, for example)
you should NOT be throwing exceptions. Erroneous data that is entered by
the user is considered the normal flow of control, and you should return
codes or something in those situations. However, if you had a primary key
violation, that's a different story, since that shouldn't ever happen, you
are more than justified in throwing an exception there.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"sloan" <sl***@ipass.netwrote in message
news:Od**************@TK2MSFTNGP02.phx.gbl...
Bingo!

Thanks Jon.

Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks.

is #1 on his list. Perfect!

..
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*******************@msnews.microsoft.com...
>sloan <sl***@ipass.netwrote:
Does anyone have any good articles on Exception Handing in DotNet.
As a "get rid of the API mode of knowing if something worked, we're not
in
VB6 land anymore Dorothy".

http://blogs.msdn.com/kcwalina/archi...16/396787.aspx

is a very good set of guidelines on when to use exceptions and when not
to, IMO. There are exceptions to the guidelines, of course...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too


Apr 26 '07 #6

P: n/a
I suspect that coders that like to return error codes just feel
comfortable with
them as they are pretty standard fare for C++ Windows coders. One
approach is
to refer them to the guru of C++ who argues for the use of exceptions
over
error codes.

In C/C++ Users Journal (August 2004), Herb Sutter has argued for a
strictly
defined domain of an "error" and the use of exceptions over error codes.

Herb Sutter concludes "Distinguish between errors and non-errors. A
failure is
an error if and only if it violates a function's ability to meets its
callees' pre-
conditions, to establish its own post-conditions, or to establish an
invariant it
shares responsibility for maintaining. Every thing else is not an
error...

Finally, prefer to use exceptions instead of error codes to report
errors. Use
error codes only when exceptions cannot be used ... and for conditions
that are
not errors."

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Apr 26 '07 #7

P: n/a
Wasn't it Einstein who said, "Insanity is the process of doing the same
things over and over, and expecting different results." ?
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"sloan" wrote:
Dude,

I've been patient. I've tried examples, making KB's, going to their desk to
help.
Asking, being nice. I'm about as helpful as I can be when it comes to
trying to help.
I think they think because I work with them, that they think I don't know
what I'm talking about sometimes.

I need something that is more "official" then my advice and home made KB's I
guess. Thus my post.

Anyway, thanks for the encouragement.

..............

Patience is definately a lost art these days.


"Peter Bromberg [C# MVP]" <pb*******@yahoo.yabbadabbadoo.comwrote in
message news:60**********************************@microsof t.com...
Hehe.
You have to be patient, Sloan.
Explain to them that the caller of this method should wrap their call in a
try / catch block and be prepared to accept the fact that they may get
back
an exception.

And just explain why they should not populate some return "string" with
the
exception message property and instead, throw the actual exception itself.

-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"sloan" wrote:
>
>
Does anyone have any good articles on Exception Handing in DotNet.
As a "get rid of the API mode of knowing if something worked, we're not
in
VB6 land anymore Dorothy".
>
>
I have a few people at work who keep writing code like below.
>
>
public string UpdateEmployee
{
string returnStatus = string.Empty;
try {
Database db = this.GetDatabase();
DbCommand dbCommand =
db.GetStoredProcCommand("dbo.[uspAAAAAAAAAAAAAA]");
(dbCommand);
>
db.ExecuteNonQuery(dbCommand);
>
>
}
>
>
>
catch (Exception ex) {
sStatus = "ERROR updating Examiner table: " + ex.Message;
}
>
>
return returnStatus;
>
}
>
>
and I need some reference(s) to put a stop to this mess.
>
>
At least with API, you checked for = or != to 0.
>
err.Number
case --020303000003003
msg = "The blah blah blah failed"
>
Those were good times.
>
Any good articles are appreciated (esp if the directly tackle this
situation )
>
>
>
>
>
>
>
>


Apr 26 '07 #8

P: n/a
Nicholas ,

Yeah, I've been looking at the Data Validation Block in the next version of
EnterpriseLibrary.
And how its not thru exceptions.

But I appreciate the extra info.
...
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:Oq**************@TK2MSFTNGP05.phx.gbl...
sloan,

One thing though, be VERY aware of this recommendation:

Do not use exceptions for normal flow of control

Basically, for logical errors (validating business logic, for example)
you should NOT be throwing exceptions. Erroneous data that is entered by
the user is considered the normal flow of control, and you should return
codes or something in those situations. However, if you had a primary key
violation, that's a different story, since that shouldn't ever happen, you
are more than justified in throwing an exception there.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"sloan" <sl***@ipass.netwrote in message
news:Od**************@TK2MSFTNGP02.phx.gbl...
Bingo!

Thanks Jon.

Do not return error codes. Exceptions are the primary means of reporting
errors in frameworks.

is #1 on his list. Perfect!

..
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*******************@msnews.microsoft.com...
sloan <sl***@ipass.netwrote:
Does anyone have any good articles on Exception Handing in DotNet.
As a "get rid of the API mode of knowing if something worked, we're
not
in
VB6 land anymore Dorothy".

http://blogs.msdn.com/kcwalina/archi...16/396787.aspx

is a very good set of guidelines on when to use exceptions and when not
to, IMO. There are exceptions to the guidelines, of course...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too


Apr 26 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.