What would be the best way to handle errors in parallel programs?

Question

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?

• Graviton: Shouldn't this be belonging to stackoverflow?
• zneak: @Ngu Soon Hui It's subjective and it's about features that don't necessarily exist, so I think it belongs here.
• bzlm: But it's about programming, not programmers. :)
• zneak: @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.

Answer 1

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.

• Pax Noctis: I second callbacks. The idea above seems pretty perfect to me.

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

• Mark H: "returning something" - to who? The caller has already moved on.
• zneak: 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.
• user1842: @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.
• zneak: 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.