On Friday 21 of August 2009 23:12:23 Ciaran McCreesh wrote: > On Fri, 21 Aug 2009 23:09:33 +0200
> Maciej Mrozowski <reave...@poczta.fm> wrote: > > I suggest #5 - drop the idea of 'nonfatal'. > Then how do you plan to handle all the standard utilities that die on > failure in EAPI 3? >>> #1 make die respect nonfatal The most obvious. About consequences - when you override behaviour of "die-on- failure" function (that has been marked as fatal for reason) you're supposed to know what you're doing, so all codepaths should be checked in that case, otherwise one should be really ready to grab the pieces in such case. >>> #2 make die always die In such case nonfatal is useless as it's supposed to surpass "die-on-failure" EAPI3 functions, am I right? Correct me if I'm wrong, bug there are just two ways to mark function invocation as 'failed': - return nonzero value - soft way - abort further execution of script, so call die function - hard way In such case nonfatal works against its purpose (it cannot interfere in arbitrary function's flow control, and return value only affects this, so the only mean for it is to interfere in general-purpose-die-function). This could be fixed by introducing 'even-more-fatal' way of aborting script execution, like function 'really-die-seriously-this-time' that ignores 'nonfatal' :P (which leads us to #3 and #4). >>> #3 add a new die variant that respects nonfatal Seems the most reasonable to me, but should be introduced with caution (if at all). It's very old question how to approach flow control: whether to: - maintain in using 'do_it_now_think_later' approach (exceptions' handling, nonfatal) - 'do_it_now_think_now' (checking return values) Ideally would be to have just one. And if the goal is to implement exception-handling-like (actually catching and ignoring) approach in flow control for EAPI3 instead of relying on return value (|| die) with runtime errors throwing (current 'die'), one would need not just one or two "die functions", but maybe whole family, with different fatality levels (for example controlled by environment variable, so that one could ignore those with level > 0 or could be more strict and only ignore those with level > 2, when 0 would be the most fatal, 1 less-lethal and so on). >>> #4 make regular die respect nonfatal, and add a new variant that doesn't) we should go with? All existing 'die' invocations now are supposed to be fatal (according to definition in devmanual), so making them maybe-fatal in EAPI3 is wrong imho. General problem is defining what's really fatal and what's not - and I can assure that someone in a future will find some use case for preventing aborting of execution of some fatal function that failed. That being said I don't like refraining from "return value approach" towards "exception handling approach" (and I'm ebuild/eclass developer and I don't see adding || die very disturbing) that has been proposed for EAPI3 in die-on- failure utility functions, and thus I don't like nonfatal (which is of course needed for them). -- regards MM
signature.asc
Description: This is a digitally signed message part.
