• (nodebb)

    I never liked abortions. Have they considered not starting the thread in the first place?

  • (nodebb)

    Sometimes I'm the first into the lab. I just pull the plugs on the instruments. They'll start up again cleanly? Won't they?

  • Little Bobby Tables (unregistered) in reply to OllieJones

    I just hit the b100dy things with a hammer till they stop making that stupid whining, whistling, beeping noise. That'll learn 'em.

  • Atomizer (unregistered)

    The real WTF is the non-atomic overwriting of files.

    Even without the Abort(), there may be 1000 reasons for the program to be terminated by other reasons.

    Even if C# didn't provide a proper library for atomic writing to files, a poor man's solution like "write to new file, move new file over original file" would be a huge improvement over not caring at all.

  • Jens (unregistered)

    Not providing catch() isn't the same as doing catch(ThreadAbortException) {}. One catches nothing, the other catches and ignores only ThreadAbortException. It also isn't true that the aborted thread doesn't get a chance to stop -- it receives a ThreadAbortException, which it can handle.

    But all in all there is a fair bit of code smell from the "logical" use case StopRun(StopReason.Completed) which in turns calls Thread.Abort(). Someone didn't think something all the way through to a proper implementation.

  • (nodebb)

    "In .NET, an aborted thread has no chance to do any cleanup or shutdown. It just ends." Uhm, no. Allowing aborted threads to clean up is the reason ThreadAbortException exists.

  • (nodebb) in reply to Jens

    In fact, thanks to the special case made for ThreadAbortException, the catch(ThreadAbortException) {} is the same as no catch at all: When a thread is aborted, the ThreadAbortException can't be swallowed: If caught and not explicitly rethrown, it's rethrown anyway, all the way up until control leaves the thread procedure.

  • Brian Boorman (google)

    TRWTF is bashing a person whose primary job isn't writing software for making mistakes while writing some software. The hubris of you people.

    What percentage of research grants would you say include enough funds to pay for a dedicated software developer to write data collection and analysis routines? I bet if it's not 0% it's pretty close to 0%. You're lucky to pay a couple of grad students to help out. Especially if you need to buy/build equipment to do the research with.

  • Nathan (unregistered)

    What about the finally block containing if (Thread.CurrentThread != RunThread) That indicates the possibility we committed suicide via the Abort call. In which case, how would we ever get here? (or does .NET CurrentThread not mean what I'm guessing it means?)

  • (nodebb)

    I think catching thread abort exception but not suppressing the abort using a special method doesn't cancel the abort. In this way, this exception is different from every other exception in .NET. So that empty catch is useless.

  • (nodebb)

    Fun fact: C# lets you omit the catch and do a simple try/finally pair.

    But wouldn't the ThreadAbortException bubble up in that case? This way it's discarded rather than delayed.

  • Vilx- (unregistered)

    To all those not familiar with .NET - calling Thread.Abort() DOESN'T immediately kill the target thread. It raises the ThreadAbortException in that thread, wherever it was at that point. Mind you, if it was in the middle of writing an XML, that'd probably get interrupted. Anyways, ThreadAbortException is special. You can catch it, and finally{} blocks do get executed, but once you're outside again it just gets re-raised automatically. You need to call Thread.ResetAbort() to stop this.

    So, the above code is pretty much WTF, but not for the reasons Remy described.

  • markm (unregistered) in reply to Atomizer

    "Even if C# didn't provide a proper library for atomic writing to files, a poor man's solution like "write to new file, move new file over original file" would be a huge improvement over not caring at all."

    Or rename old file, then write new file. This needs to handle an exception to the rename operation, e.g. if the old file is locked; do you see any better way to save the new data than to write the new file to a different name? Your way, if the original file is locked, you already have a new file under a different name, and either way the user has to go in under Windows Explorer and find the new file.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    Related reading: never call TerminateThread()

    https://devblogs.microsoft.com/oldnewthing/?p=91811

  • (nodebb) in reply to kazitor

    It bubbles up anyway. ThreadAbortException is special that way.

  • zybex (unregistered)

    In France, if a thread is running for more than 10 weeks you cannot abort it. Unless the thread was coerced into existence.

  • Atomizer (unregistered)

    @markm: Your proposal does not implement atomicity at all. Please do not implement atomicity that way!

    Instead, I strongly recommend to use a popular, battle-tested library.

    If you are really interested in the details of how to implement atomicity correctly, you might want to have a look at one of those libraries. For example, the Python library "atomicwrites" handles quite a lot of corner cases, for Windows, Mac and Unix:

    https://pypi.org/project/atomicwrites/

    For a deeper look into all the nitty-gritty problems that such a library needs to solve, please read:

    https://danluu.com/file-consistency/

  • eric bloedow (unregistered)

    i seem to remember an old story where a programmed apparently never HEARD of "stop" or "end" and used an intentional "divide by zero" error instead!

  • Wizofaus (unregistered) in reply to Brian Boorman

    Trend to agree, and I'd also say even experienced dedicated programmers frequently do a poor job of ensuring their code handles early/unexpected termination (including power failure etc). Which tells me TRWTF is at a more fundamental level - why can't Operating Systems provide the necessary support that means programmers don't need to write code for every application to deal with such scenarios, in much the same way the TCP/IP stack obviates the need for coders to worry about network packet misdelivery issues.

  • Roman (unregistered)

    Fun fact: C# lets you omit the catch and do a simple try/finally pair.

    Fun fact: if you omit the catch clause, the exception won't be caught and will propagate out of the try clause.

    Empty catch clauses are certainly a code smell, but they are in no way redundant; they actually affect program behaviour.

Leave a comment on “It Just Won't Stop”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article