Re: ReaderWriterLockSlim + Dispose?

On Mon, 07 Apr 2008 11:01:48 -0700, NvrBst <nvrbst@xxxxxxxxx> wrote:

[...]
Amusing, are there any other requirments? Am I allowed to use if
statments? :) Its a joke :P. You say "it doesn't crash", but thats
not just the case, you should be saying "it doesn't crash, and
maintains the strick sychronization requirments", and all other
requirments/functions of the program for that matter, with no
possibility of ill effects. It does exactly what the client paid for,
and doesn't have any dead weights running around.

Exceptions are costly, and so it's certainly not true that your design "doesn't have any dead weights running around". As far as the question of "no possibility of ill effects", in your specific example that's true, but you can't extrapolate that to any arbitary implementation that uses the same technique.

I don't know why you wouldn't call it a valid design, it uses a
boolean to check the object before using it, and in the rare case of
object being disposed between the ")", then it does whatever cleanup
the thread might want to do, and exit, in a valid way to maintain
sychronization.

Why do you bother checking the boolean at all? It's not protecting you in any way.

It's a bad design because it has code that tries to do something, but because you haven't designed the code to be reliable, you wind up having to add a bandage to catch the fact that the code isn't reliable.

This code performs its duty perfectly:

try
{
string[] rgstr = { "one", "two", "three" };

for (int i = 0; i <= rgstr.Length; i++)
{
Console.WriteLine(rgstr[i]);
}
}
catch { }

But that doesn't mean that it's been designed correctly. And in fact, it hasn't been designed correctly. The above is just like your proposed "catch disposed exception" solution, which is just as incorrect a design..

From what your saying here it's like you've never opened a file in
your life as a programmer (which is the same design pattern as I'm
using).

Opening a file and catching a possible failure is nothing like the design pattern you're using. Just because both examples use try/catch, that does not make them the same design pattern. Still, the "open file" pattern you describe is just as flawed as the "catch disposed exception" pattern you're promoting. Specifically...

You check the file to see if its valid, and then open it.
Can something grab the file between the check and opening? Definally,
does it make it a bad design? Definally not.

Writing code that checks a file to see if it's valid and then tries to open it is stupid. Because of the exact issue you're describing, there's absolutely no point in doing any verification of the file before opening it. You should just try to open it. That's your verification right there.

You show me a method of opening a file without a try/catch statment
that doesn't crash, and I'll show you how to check for use of a
disposable object that can be disposed anytime.

The two situations are entirely different. It's trivial to write code that doesn't need to catch an "object disposed" exception. But as you pointed out, because the file system is not under the process's control, there's no way to ensure that opening a file won't throw an exception.

Rest of your statments are just plaintly close minded. Telling people
there is no way to do something (correctly), is extremly ignorant,

You're welcome to your opinion. But I'm welcome to mine too, and I certainly am of the opinion that it's extremely ignorant to write code that throws exceptions when you could just as easily write it correctly and without the code failing intentionally.

"I hope no one is paying you for your coding efforts then" with that kind
of mindset, a real programmer see's a problem, and accoplish's it.

No. A real programmer doesn't just make his program work. He designs it with care and attention to detail, making it maintainable, robust, and efficient. He does not just add duct tape until the thing works. He strives to make the solution as elegant as it is useful.

Pete
.

Relevant Pages

  • Re: The origins of CL conditions system
    ... Machine experience explaining the Lisp Machine error handling. ... languages with continuable exceptions (including Mary Fontana from TI ... Why can't I resume after catching an exception? ... exception handling chapter of The Design and Evolution of C++. ...
    (comp.lang.lisp)
  • Re: CInternetSession
    ... the presence of the Sleepindicates the serious design flaw. ... Sleep() calls around like pixie dust, your design is fundamentally broken and will need to ... If you use Sleepin a loop, your design is probably wrong and needs to be ... The "First Chance Exception" message usually indicates nothing harmful. ...
    (microsoft.public.vc.mfc)
  • Re: Throwing exception in a try block?
    ... it seems that this programmer is part of you group. ... tenets of good exception practices. ... > catching exceptions so that you can do some sort of rollback or cleanup ... > and then throw an exception then it could be a fine design. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [announcement] SYSAPI and SYSSVC for Windows
    ... Windows is the actual design problem, ... exception would just have to be a tagged type. ... Observe that the following is absolutely legal and works in Ada: ... The compiler checks that Data_Error cannot propagate out of f. ...
    (comp.lang.ada)
  • Re: Anonymus functions revisited
    ... > If the exception is the problem, ... Why should we assume the concept or design ... Suppose we have an algoritme ... > of lambda, at least not in this example. ...
    (comp.lang.python)