Making EPERM friendlier, even for C++ programs [LWN.net]

Making EPERM friendlier, even for C++ programs

Posted Feb 2, 2013 12:43 UTC (Sat) by MrWim (subscriber, #47432)
In reply to: Making EPERM friendlier, even for C++ programs by scripter
Parent article: Making EPERM friendlier

This is also a frustration of mine. Most exception propagation schemes make only two options easy:

Allow the exception to propagate (e.g. "cannot convert 'abc' to int") such that the UI can only tell the user exactly that but not more information about the context
Catch all exceptions and throw another one with context but not (e.g. "Loading simulation failed")

It is far too difficult to provide an error message like "Loading simulation failed because cell B74 of sim.csv contains 'abc' when it should contain a number". It would be nice if it were possible to attach more and more context to an exception as it propagates up the stack. Java has exception.getCause() and C++'s boost::exception has the ability to attach more data to an exception.

I prefer boost's approach but it still sucks as:

You still need a try...catch block. It would be much nicer to have some sort of RAII style context built up on the stack which would be unrolled.
To use it all the code you call must throw boost exceptions.
It is difficult to serialize/deserialize if you want to transport it between threads.

I don't know if other languages have solved this in a nicer way.

(Log in to post comments)

Making EPERM friendlier, even for C++ programs

Posted Feb 2, 2013 23:22 UTC (Sat) by etienne (subscriber, #25256) [Link]

Maybe you want something like the lower quartet/byte indicate the error, the function up the stack adds its quartet/byte (shifted by 8 bits) to tell when that error happens, and go up for next quartet/byte. The problem then is to document all the error codes you show to the final user...

Making EPERM friendlier, even for C++ programs

Posted Feb 3, 2013 0:37 UTC (Sun) by nix (subscriber, #2304) [Link]

That doesn't let you include more than a few functions' worth of info, and *also* doesn't let you include a string with variable components.

Doing this gets even more painful when you consider localization. Even GNU gettext, with its support for %s-style elements whose order depends on language, would have trouble here, I fear.

Making EPERM friendlier, even for C++ programs

Posted Feb 3, 2013 19:16 UTC (Sun) by MrWim (subscriber, #47432) [Link]

Not relevant for this discussion perhaps but maybe such a system would be possible in C++. See my code-sketch: https://gist.github.com/4697481 . Even so it would probably be difficult to make this efficient enough and malloc failure friendly that people would actually want to use it.