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

  • Thread starter Thread starter sloan
  • Start date Start date
S

sloan

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 )
 
Bingo!

Thanks Jon.

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

is #1 on his list. Perfect!

...
 
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
 
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 said:
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 said:
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 )
Click to expand...
Click to expand...
 
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]
- (e-mail address removed)

sloan said:
Bingo!

Thanks Jon.

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

is #1 on his list. Perfect!

..
Click to expand...
 
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
 
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 said:
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 said:
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 said:
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 )
Click to expand...
Click to expand...
Click to expand...
 
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 said:
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.
Click to expand...
 
Back
Top