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?

zneak
  • 2,596
  • 2
  • 23
  • 24

2 Answers2

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.

Shog9
  • 8,101
  • 2
  • 46
  • 56
-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.