12

With parallel algorithms knocking at the door, it might be a good time to think about error handling.

So at first there were error codes. Those sucked. It was free to ignore them, so you could fail late and produce hard-to-debug code.

Then came exceptions. Those were made impossible to ignore once they occur, and most people (except Joel) like them better.

And now we got libraries that help parallel code. Problem is, you can't handle exceptions in parallel code as easily as you could with non-parallel code. If you asynchronously launch a task and it throws an exception, there's no stack trace past it to unwind; best you can do is capture it and register it on the task object, if there's such an object. However, it defeats the primary strength of exceptions: you have to check for them and you can ignore them without any additional effort, whereas in single-threaded code an exception will necessarily trigger the appropriate actions (even if it means terminating your program).

How should language implementations or libraries support errors in parallel code?

Improve this question
4
  • 2
    Shouldn't this be belonging to stackoverflow?
    – Graviton
    Commented Sep 15, 2010 at 15:52
  • @Ngu Soon Hui It's subjective and it's about features that don't necessarily exist, so I think it belongs here.
    – zneak
    Commented Sep 16, 2010 at 0:46
  • But it's about programming, not programmers. :)
    – bzlm
    Commented Sep 16, 2010 at 7:10
  • 1
    @bzlm FAQ says "Programmers - Stack Exchange is for expert programmers who are interested in subjective discussions on software development." and SO explicitly discourages subjective discussions.
    – zneak
    Commented Sep 18, 2010 at 19:04

2 Answers 2

Reset to default
3

I'm rather fond of callbacks for errors that can be handled. And they can be made to work just fine asynchronously...

But for errors that can't be handled, truly exceptional errors, I'd rather see the relevant information saved and the program terminated. Since this is usually accomplished via some sort of global error-handler anyway, I see no need to twist exceptions into something that works for this - but better platform support for detecting critical errors and producing memory dumps, etc. would be nice.

Improve this answer
1
  • I second callbacks. The idea above seems pretty perfect to me.
    – Pax Noctis
    Commented Sep 17, 2010 at 3:12
-2

Seems like you would want to make sure that the task handled it's own exceptions, and then returning something that let the calling program know that the thread needed to be shut down. It would then have logic to process the result of all threads, knowing that some of those threads had failed.

Improve this answer
4
  • 5
    "returning something" - to who? The caller has already moved on.
    – Mark H
    Commented Sep 15, 2010 at 0:45
  • As @sparkie said, you can't just do that. Even if you keep the call stack as a root for the coroutine, the caller will probably be far, far away. As I mentioned, exceptions were designed so they stop your program, now. Checking for it yourself later defeats it completely as exceptions could undergo unnoticed.
    – zneak
    Commented Sep 15, 2010 at 3:17
  • @Zneak, I suppose when I mentioned exceptions I wasn't using your (standard) definition, I just meant the error was caught. After any function is finished it has to return to somewhere, at that point the "exception"/error can be dealt with (at that level). I'm not sure why you guys are referring to the calling program being far away, any return value from the function has to be dealt with in someway. I realize that this won't work nearly as well if the results of the threads mesh with each other dependently.
    – user1842
    Commented Sep 15, 2010 at 15:19
  • 1
    Not all parallel tasks "return" somewhere. For instance, you could just delegate a long task to a separate thread while doing something else on the main thread, (wrongly) without ever wondering if it completed correctly. For instance, I could write an image edition software that writes to files from a secondary thread, and return from the save dialog as soon as the task is started. I won't need the return value, whatever it is, for any further operation, so except for errors, there's no reason to check it.
    – zneak
    Commented Sep 18, 2010 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.