Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

On 5/6/2018 1:19 AM, Lawrence D'Oliveiro wrote:
> On Sun, 6 May 2018 00:11:12 +0200, Gregor Mückl wrote:
>
> > Just don't assume that you know better than the creator of the host
> > program when it is okay to bail and how to do so.
>
> As the provider of the lower-level abstraction, you guarantee certain
> invariants. In this case, that every FT_Face has a driver, and the
> driver has knowledge of that FT_Face as long as it exists.
>
> If that invariant breaks, there’s nothing that the caller can
> reasonably do about it, because it’s none of the caller’s business.

This is where you reasoning is wrong. The abstraction is that the caller 
does not need to understand the exact nature of the error.

Error handling code rarely concerns itself with the exact error that 
happened, because they typically lead to the same handling strategies in 
the caller anyway. FT_Done_Face is also on this category.

(the only class of functions that I can think of that requires the 
caller to differentiate between error codes are a few blocking system 
calls that suffer from occasional spurious wake ups).

> That’s what “abstraction” means.
>
> > This is highly dependent on the actual purpose of the program ...
>
> In that case, perhaps you could show us an example or two of how you
> deal with error returns from FT_Done_Face?

There are two choices here:

1. ignore it
============

From actual code that I wrote about 6 years ago:
-----
	// Freetype could return an error code here, but it's not particularly 
useful to respect it
        FT_Done_Face(TL_Globals.fonts[font].face);
-----

Strictly speaking, this code is wrong, but this was for a game engine, 
so the worst thing that can happen is the player getting angry at a 
crashing game.

2. propagate the error up
=========================

Example using some C++ library code of mine:

-----
        if(FT_Done_Face(face != 0) {
                throw gltb::Error("Freeing Freetype font failed", 
"TL_UnloadFont()");
        }
-----

In my main() functions there always is the following corresponding code 
around everything:

-----
int main(int argc, char *argv[]) {
        try {
                // actual program code
        } catch(gltb::Exception &e) {
                std::cerr << e.asFormattedText() << std::endl;
                return 1;
        }
        return 0;
}
-----

The important part here is that the constructor of gltb::Error records 
the actual runtime callstack of where it was executed, that is, how the 
throw statement was reached in the exection flow of the program. And its 
asFormattedText method turns it into a readable string. In various 
cases, I have dumped this string onto the console (as in the example 
above), shown this in a Windows message box (no console there) and 
written it into a log file that a user can locate in the file system and 
send to me.

Also, on the way up to the exception handler in main(), stack unwinding 
causes destructors of various objects to be called. That way, RAII 
patterns in my code get executed: resources are freed, files are closed 
(writing buffered file contents to disk) etc.

This would not work if you just blindly call exit() or abort().