[Scummvm-devel] PROPOSAL: Removing (f)printf usage

[Max Horn]

Am 07.11.2010 um 05:17 schrieb yotam barnoy:

>> On 11/07/2010 02:58 AM, Max Horn wrote:
>>> thanks for the feedback! Since nobody seems to have much of an opinion on the API, I'll just do it according to your comments:
>>>   OSystem:: logMessage(ConsoleMsgType type, const char *msg);
>>> with
>>>   enum ConsoleMsgType { ERROR, WARNING, DEBUG };
>>> and no OSystem::flushLog() method. It's trivial to adjust these things once we have them anyway.
>> 
>> LogMessageType please and not ConsoleMsgType :-).
> 
> Looks good to me
> 
>>>>> 2)  OSystem::fatalError()
>>>>> This would by called as last thing by error(), and by default would invoke OSystem::quit() followed by exit(1). Look at the end of our current error() function in common/textconsole.cpp to get an idea of what other things backends might do there.
>>>>> 2b) Alternatively, this function could be part of OSystem::logToConsole, and triggered by message type FATAL_ERROR.
> 
> I'm not so happy about our current behavior here.

Yotam,

you have a good point, but one I feel is a bit misplaced in this discussion. It's well worth opening a new discussion, though

Yes, handling error by bailing out / crashing is not a good way. Engines should instead check better for error conditions, and try to handle them as gracefully as possible, e.g. by returning to the launcher, showing a dialog, etc.

But this is not something we can address by any piece of generic code. And there will always remain some errors that an engine cannot handle. So, no matter what, we need a way to handle fatal errors. The best we can do is to not call exit() directly, but at least allow the backend to try to "crash land the plane" as good as possible. Which is what we are trying to do here.


Our error method, and our assert method, are one-way tickets. Something that code is guaranteed that will not return. And we cannot break that promise now, as that would not lead to more graceful error handling, it rather would things much, much worse.

Everybody here is of course most welcome and encouraged to come up with ways (e.g. in the forms of APIs, examples, actual code modifications etc.) that help existing code to deal with error situations more gracefully. Modifying error() and assert() is *not* the way to achieve it, though. 


Bye,
Max