Re: Defensive Programming - Where do you Draw the Line?
- From: "sloan" <sloan@xxxxxxxxx>
- Date: Tue, 2 Oct 2007 15:36:34 -0400
That's true as well.
That I would put under personal preference.
I guess I've just been sticking to what Brad went over moreso than the
"using", even though as I've migrated to 2.0/3.0, I do more using
statements.
"Chris Mullins [MVP - C#]" <cmullins@xxxxxxxxx> wrote in message
news:%23A8K%23cSBIHA.4752@xxxxxxxxxxxxxxxxxxxxxxx
It's funny, but I've always disliked the Try/Finally syntax. I may be the
only one, but... ick.
I find myself writing specialized classes, and then using Using blocks
everywhere. This way I'm exception safe, and I don't end up with 10 or so
extra lines of code in each method.
public class ReaderLock : IDisposable
{
private ReaderWriterLock _rw;
public void ReaderLock (ReaderWriterLock rw) { _rw = rw;
_rw.EnterReadLock();}
public boid Dispose () { rw.ExitReadLock();}
}
Then all my code ends up looking like (4 lines of code):
using (new ReaderLock(collectionRWLock))
{
// ... code goes here
}
instead of (9 lines of code):
collectionWRLock.EnterReadLock();
try
{
// Code Goes here
}
finally
{
collectionRWLock.ExitReadLock();
}
I just don't like all the extra lines of the try/finally, and the visual
verbosity they bring for no real benefit. Especially if you're not doing
anything meaningful in them.
--
Chris Mullins
"sloan" <sloan@xxxxxxxxx> wrote in message
news:euD5hWSBIHA.3900@xxxxxxxxxxxxxxxxxxxxxxx
I concur
try
{
}
finally
{
}
blocks should exist in your code ALOT more than
try/catch or try/catch/finally blocks.
Brad Abrams talked about this as well when he visited our UserGroup
http://msdn2.microsoft.com/en-us/library/ms229005(VS.80).aspx
//Quote//
Do use try-finally and avoid using try-catch for cleanup code. In
well-written exception code, try-finally is far more common than
try-catch.
The purpose of a catch clause is to allow you to handle exceptions (for
example, by logging a non-fatal error). The purpose of a finally clause
is to allow you to execute cleanup code regardless of whether an
exception was thrown. If you allocate expensive or limited resources such
as database connections or streams, you should put the code to release
them inside a finally block.
"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.216c9adf71fec1ad4e4@xxxxxxxxxxxxxxxxxxxxxxx
Smithers <A@xxxxx> wrote:
Please consider this humble method:
public void ResetCounters()
{
m_TotalExceptionsDetected = 0;
m_TotalMessagesSent = 0;
}
Given no further information, would you wrap those two lines in a
try...
catch block?
The above is a specific example of a more general question... when an
exception is incredibly unlikely to occur, is there any good reason to
add
error handling, assertions, and other validation code?
I write very few try/catch blocks. I write far more try/finally blocks,
usually implicitly with "using" statements. Well-written error-handling
code *tends* to be at a very high level, indicating that something
within a potentially very deep stack has failed. There's often no need
to handle the error other than at the top level.
The bigger picture is this: I'm rewriting a few utilities that I wrote
a few
years ago. They have been humming along just fine in production. As
part of
my current refactoring-from-1.1-to3.5 effort... in addition to adding a
few
new capabilities, I'm wanting to make things more "bullet proof" - not
out
of necessity (such tasks would have been done by now), but more for the
sake
of doing it "right" or at least better. So I look at the above and
think
that it's so incredibly unlikely that anything would ever go wrong with
that - so is there any reason to add the extra code - little as it may
be -
for a try... catch block.
What would you even do in the catch block? You can't really recover
from the error. The best you could do is log and then rethrow - but in
that case, you might as well catch at the top level and log there.
Do any of you actually put at least one try... catch block in *every*
method
you ever write? If not, when do you NOT put one in for reasons other
than
laziness?
It should be the other way round - if your method fails to execute,
what good reason do you have for *not* just letting the exception
bubble up? How are you going to add value to that error-reporting
mechanism? Can you recover from the error?
--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.
- References:
- Defensive Programming - Where do you Draw the Line?
- From: Smithers
- Re: Defensive Programming - Where do you Draw the Line?
- From: Jon Skeet [C# MVP]
- Re: Defensive Programming - Where do you Draw the Line?
- From: sloan
- Re: Defensive Programming - Where do you Draw the Line?
- From: Chris Mullins [MVP - C#]
- Defensive Programming - Where do you Draw the Line?
- Prev by Date: Re: Syntax Question - meaning of tilde (~)
- Next by Date: Re: Defensive Programming - Where do you Draw the Line?
- Previous by thread: Re: Defensive Programming - Where do you Draw the Line?
- Next by thread: Re: Defensive Programming - Where do you Draw the Line?
- Index(es):
Relevant Pages
|
