1 |
On Friday 21 of August 2009 22:56:41 David Leverton wrote: |
2 |
> Does anyone have any opinions on which of the four options (#1 |
3 |
> make die respect nonfatal, #2 make die always die, #3 add a new |
4 |
> die variant that respects nonfatal, #4 make regular die respect |
5 |
> nonfatal, and add a new variant that doesn't) we should go with? |
6 |
> We should definitely get this resolved and agreed on before EAPI |
7 |
> 3 is finalised. |
8 |
|
9 |
I suggest #5 - drop the idea of 'nonfatal'. |
10 |
|
11 |
Quoting devmanual: |
12 |
"The die function should be used to indicate a fatal error and abort the |
13 |
build. Its parameters should be the message to display." |
14 |
Period. |
15 |
In such case, following code: |
16 |
|
17 |
nonfatal some_function |
18 |
|
19 |
when: |
20 |
some_function() { |
21 |
so_sth || die "sth failed" |
22 |
} |
23 |
|
24 |
only means, that "some_function" shouldn't have been equipped with 'die' |
25 |
mechanism, as use case appeared that demands it being non-fatal. |
26 |
And in this case "some_function" should be fixed to be nonfatal instead (and |
27 |
all existing invocations suffixed by "|| die". |
28 |
Simple as this. |
29 |
Please refrain from adding silly workarounds like this - only thing they add |
30 |
is unnecessary complexity and thus maintenance/debugging burden. |
31 |
|
32 |
-- |
33 |
regards |
34 |
MM |