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

Making EPERM friendlier, even for C++ programs

Posted Jan 22, 2013 20:33 UTC (Tue) by scripter (subscriber, #2654)
Parent article: Making EPERM friendlier

While I welcome better error messages, it reminds me that there are challenges getting at the root cause in languages besides C.

For example, C++ streams haven't provided programmers with a standardized way to get at errno/strerror. There's a proposal to fix it:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n...

For g++, there's a non-standard workaround: use C calls and convert the file descriptor into a C++ stream using __gnu_cxx::stdio_filebuf<char>:

http://stackoverflow.com/questions/2746168

It's also nice to get good error feedback in higher-level languages like Java.

I get frustrated when applications swallow error messages and provide high-level "Something went wrong" messages because it makes it difficult to find and fix the root problem. I suppose that's why tools like strace and ltrace are so useful.

(Log in to post comments)

Making EPERM friendlier, even for C++ programs

Posted Feb 2, 2013 12:43 UTC (Sat) by MrWim (subscriber, #47432) [Link]

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.

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.