Unconditional printf warnings

[chrisdembia]

Some warnings are unconditionally printed to stdout (e.g. here). We would like to control the output that our library produces. Would it be possible to add a verbosity setting? The setting could default to "on" or "1", and we could override it to be zero by default in our library. What do you think?

[chrisdembia]

The other option would be to remove the printf's (so the user would need to read the errcmaes file for info), though I think it would be nice to be able to print messages to the console.

In either case, I'm happy to do the implementing, with your guidance.

[nikohansen]

The two printf's close to the above link are essentially fatal errors. The algorithm should never be launched with the default value for initial X or for initial sigma, unless for pure debugging/test purpose. This suggests that removing these is not an option, while they could be replace with a call to FATAL.

[sherm1]

The difficulty for us is that we are providing a library (an API with no end user interface). People incorporate our library into user-friendly applications with nice windows-and-menus interfaces (such as the OpenSim GUI for biomedical researchers). Those applications don't necessarily have a console so there is nowhere for us to print error messages. So the messages may get lost, or interfere with the UI designer's strategy for reporting and logging.

I think it is good for libraries to display error messages by default, but when embedded in someone else's UI it is good to have an option for the UI author to be able to capture those messages to report them in a way that will make sense to the end user (in a logging window with some context about what the UI was doing, or instructions to file bug reports, or whatever).

[nikohansen]

I assume that making them FATAL (fatal errors call exit) would meet the demand, because you have to be able to deal with fatal errors anyway?

[sherm1]

In C++ we are able to do this using the exception mechanism -- instead of printing a message we throw an exception with the message embedded. The default exception handler just prints the message to the console. But the caller can catch the exception, extract the message and do whatever they want with it. It takes more engineering to do the same thing in C (like the errno mechanism for system calls).

[sherm1]

I assume that making them FATAL (fatal errors call exit) would meet the demand, because you have to be able to deal with fatal errors anyway?

Well, that depends -- fatal for the library might not mean fatal for the application in which it is embedded; the library shouldn't normally kill the app. However, it does make sense to do that when the failure represents a bug in the caller, for example if the UI passes in a negative number for a length. In that case death-with-stack-trace is probably the kindest thing the library can do.

[nikohansen]

The library implements a FATAL function which is called on unrecoverable errors and which calls C exit. Like this, the library user should be able to easily "catch" these errors, e.g. by redefining FATAL.