On Fri, 04 May 2007 10:27:34 -0400, Havoc Pennington wrote: > It's a run-time env variable. I think we don't advertise it at all, it's > more of a defense against people who have strong views on the topic and > prefer "undefined behavior probably a crash" to "just exit" ... And one thing to note here is that cairo does provide an additional option: "No behavior, will not crash" which I think can form a good compromise between the camps that prefer each of the options you mention. (Though I'll agree that debugging would be easier if cairo _also_ provided a run-time mechanism to get the "just exit" along with an error message giving as much context as possible for the time of the error.) The point is, while it might not make sense to talk about error recovery from any single low-level library operation, (see your "failed to draw a rectangle" example), applications still will very much want to have high-level behavior of "something has gone very wrong, let's save the user's important state before exiting". There are a few things a library could do that would defeat that almost entirely: 1. Exit 2. Start doing undefined things 3. Require error-checks on every call into the library to prevent it from doing undefined things You seem to be saying that it's impractical for a library to avoid 2 or 3, so there's no reason not to do 1. But I think with cairo we've got a practical approach for getting close enough to avoiding all three so that applications really can do high-level error recovery. And that seems useful. > When I first implemented this it found quite a few bugs, I then > implemented something similar for part of libxml and also found a lot, > so that's why my party line since has been that trying to handle OOM > without testing the OOM codepaths is more hopeful fantasy than anything > else. I absolutely agree that testing is essential, and out-of-memory handling is doomed without it. And now that we've fixed so much in cairo, we really want to go fix underlying libraries like fontconfig and freetype or else it's really all in vain. > (it's just too hard to get right without testing - in some cases > in dbus-daemon I had to implement fairly complex "transactions" that > could be rolled back, in other cases I had to change the library API to > allow e.g. callbacks to signal OOM) When we started testing cairo, we found several mistakes, (though fewer than I had anticipated to tell the truth). But we've had nothing come even close to needing any API changes. Part of that is certainly due to cairo's problem domain where there aren't a lot of complex interactions between separate operations, (can anyone imagine transactions being useful when drawing?). But another part comes from just accepting support for OOM-error- handling as an upfront design constraint, rather than hoping to bolt it on later. -Carl
Attachment:
pgp8GS4UtNkFt.pgp
Description: PGP signature