Re: ReaderWriterLockSlim + Dispose?

On Apr 6, 7:53 pm, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
wrote:
As I noted in my other post, wrapping the call in a try/catch doesn't  
address the underlying design issue, nor does it any way validate the  
design choice.  That said, I find it amusing that you don't like the idea  
of aborting a thread (as well you shouldn't), but you're perfectly happy  
to have it throw an exception that you catch and use to terminate the  
thread.  There's very little difference between the two approaches.

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.

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.

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). 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.

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.

Rest of your statments are just plaintly close minded. Telling people
there is no way to do something (correctly), is extremly ignorant, "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. He
doesn't whine about a try/catch statment, he whines about the
performance/robustness/correctness (problem wise) of a solution.

NB

PS: I'm not saying this is the only way to do things. I've made
programes with all three techniques mentioned here and will agree that
signling threads to finish and waiting for them to finish to dispose
is one way to do it. It doesn't make it the best way for all cases in
the world... unlike your mindset, the world is not that small of a
place.
.

Relevant Pages

  • Re: Laws of Intelligence -2
    ... > I was simply saying that raw materials are unintelligent. ... "design" of a wasps' nest. ... >>>animated characters in those films, and your programmer was ...
    (talk.origins)
  • Re: Another $17.4 Billion WASTED
    ... program from shrouded code is anything but "pathetically simple". ... perhaps with user-selected features and compiler ... uncommented code from a programmer that is using ... the detailed software design document put together by the PHD that ...
    (rec.autos.driving)
  • Re: Database access sucks!
    ... I do not answer questions on behalf of my employer. ... programmer helping programmers. ... > side cursors, when ADO was introduced the default was server side cursors. ... Other database access methods don't allow this goofy design, ...
    (microsoft.public.dotnet.general)
  • Re: lines of code?
    ... > goose wrote: ... >> is one that could benefit from a multithreaded design. ... against :-) java developers, ... The programmer has to figure it out ...
    (comp.lang.java.programmer)
  • Re: I need more eyes on this one.
    ... by experiencing the problems you mentioned in your code, ... coding without sufficiently thinking about the design or code, ... the worse it gets for the code and the programmer ... project management, processes, ...
    (alt.comp.lang.learn.c-cpp)