Ceph

Yeah, there are lots of these. Some hosts seem to spit out nice warnings for lots of call sites where the return value isn't checked (newer glibc i think?). It would be great to clean these up. Some care needs to be taken, though: in some cases failure is okay, in some cases a warning is appropriate, in others we should outright fail.

I suggest to avoid unchecked function calls.
Would you like to detect every error situation as early as possible?

Would you like to reduce the efforts for error code checking by an exception class hierarchy?

For something like strdup, which fails with ENOMEM, we can throw the usual C++ out of memory exception.

In general, we should check errors right away. If it's ENOMEM, throw an exception. If it's non-fatal, warn. If we can, pass the error to the caller. Otherwise... it needs a closer look! assert(r == 0) as a last resort.

Would you like to reuse any class library?

I do not like "assert" for consistent error handling because the check will not be performed if the symbol "NDEBUG" will be defined.

I would appreciate a clarification which function calls need to be kept as C style
interfaces to provide the portable ABI and which of them could use more C++ features
for their implementations.

Are there any chances to integrate higher level programming tools like AspectC++ and ACC into the software development process here?

Markus Elfring wrote:

Would you like to reuse any class library?

I do not like "assert" for consistent error handling because the check will not be performed if the symbol "NDEBUG" will be defined.

Not actually with ceph's src/include/assert.h. If it did, we'd need to keep some other 'die' helper to replace instances of assert(0) all over the code base.

I would appreciate a clarification which function calls need to be kept as C style
interfaces to provide the portable ABI and which of them could use more C++ features
for their implementations.

Are there any chances to integrate higher level programming tools like AspectC++ and ACC into the software development process here?

I have no specific rules here. I'd like to avoid too many build dependencies, though. We already use boost, so anything there is probably worthwhile.

But I wouldn't spend too much time fixing things that aren't broken, unless the existing approach is somehow not robust or it is making error handling harder or something.

The C/C++ programming language makes it easy to overlook unused return values. Which software tools do you find acceptable for the purpose to handle them all?