Emily Shaffer <nasamuffin@xxxxxxxxxx> writes: >> For example, "die() is inconvenient to callers, let's propagate >> errors up the callchain" is an easy thing to say, but it would take >> much more than "let's propagate errors up" to libify something like >> check_connected() to do the same thing without spawning a separate >> process that is expected to exit with failure. > > Because the error propagation path is complicated, you mean? Or > because the cleanup is painful? Both. The amount of data the caller may want to learn about an error may not be uneven, depending on the caller even for a single function. And yes, cleaning up of shared resources like object flag bits after a traversal, especially a failed one, would be very painful unless the processing is designed from day one to allow it (and the revision traversal codepath is not). > ... is it reasonable to consider, for example, further > cleanup of cache.h as part of this effort? Is it reasonable to rework > an ugly circular dependency between two headers as a prerequisite to > doing library work around one of them? I am not sure about which two headers you are talking about, but if there is circular dependency that can be untangled, it would be a reasonable preliminary clean-up work. I am not sure if that is "prerequisite"---it is up to folks who want to design how the "libification" work goes.
