• that other guy (unregistered)

    Frist unrecommended comment

  • bvs23bkv33 (unregistered)

    unfirst recommended comment

  • RLB (unregistered)

    As Hannah Glasse didn't actually write: to eat your exception, first catch your exception.

  • (nodebb)

    You can't have your exception and eat it.

  • rosuav (unregistered)

    You may not have dessert until you've eaten all your exceptions.

  • Little Bobby Tables (unregistered)

    Seriously though, why don't we talk about "eating" rather than "consuming" in this context?

    "Hey, you laddie! If you don't eat your exceptions you can't have any Wait()! How can you have any Wait() if you don't eat your exceptions?"

  • Thanks (unregistered) in reply to Little Bobby Tables

    Got something to listen to again ;)

  • gumpy_gus (unregistered)

    Funny you should bring this up, I'm currently trying to fix an app that has quite a few catches and while some try to print a message, a goodly handful do nothing at all, or put up an empty dialog box. Not fun.

  • (nodebb)

    Uhm, from the documentation, Task.ContinueWith does work with tasks that throw an exception, unless the flag TaskContinuationOptions.NotOnFaulted was passed...

  • Loren Pechtel (google)

    Knowing how to disable the warning over an empty exception handler doesn't mean you routinely ignore exceptions.

    Look at how programs respond to missing/damaged configuration files. The general pattern I have seen is to load what you can, say nothing and continue. So long as you don't then try to update the configuration this won't cause harm.

  • sizer99 (google)

    The code specifics aside.... Netscape Navigator used to do this. It was so buggy it had a top-level catch/ignore, and then a lot of code in there to try to ignore threads dying. It was the only thing we ran that could and did regularly hard lockup X.

  • Mike Rosoft (unregistered)

    I'll catch an exception ... and eat it!

  • (nodebb)

    Code this bad used to be necessary.

    Before async/await, it used to be that unobserved task exceptions would crash the process. This was a deliberate decision since Tasks catch exceptions from their delegates and store them on the Task instance. This old behavior would have the Task finalizer check to see if the exception was ever observed, and if it wasn't, to deliberately re-raise it directly on the thread pool, which would by default crash the process.

    Calling Wait() on a completed Task is one way to observe exceptions, though it would also raise that exception (hence the try/catch). Before async/await, the only way to attach a task continuation was with ContinueWith, so that's the only place it makes sense to put this code.

    In conclusion, as bad as this code seems today, in the world before async/await, there was no other way. You could clean it up a bit by reading the Task.Exception property instead of doing Wait with try/catch, but that's the only available improvement.

    As soon as async/await came out, several things changed; continuations are (usually) more naturally expressed with await rather than ContinueWith, and the runtime behavior was also changed to not crash, so the modern way of ignoring exceptions can be as simple as:

    Task _ = SomethingAsync();

    Although it should be noted that ignoring exceptions still isn't recommended. :)

  • Ross Presser (google)

    TRWTF is that Remy put a cornify link in, which doesn't work, and that cornify has an expired certificate.

  • Richard (unregistered)

    That ".ConfigureAwait(false)" call is completely pointless. It only has an effect if you await the returned task, which isn't happening here.

    All it does is tell us that the code was written after async/await were introduced, making this method extra useless.

Leave a comment on “Strongly Unrecommended”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article