Re: [gentoo-dev] EAPI 3 and "nonfatal die"

[Maciej Mrozowski]

On Friday 21 of August 2009 23:12:23 Ciaran McCreesh wrote:
> On Fri, 21 Aug 2009 23:09:33 +0200

> Maciej Mrozowski <reavertm@××××××.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