Wow. That's really nice. I've always hated overloading the meaning of undef or 0 (as you have to do in C). Having an explicit "failure" value makes life a lot nicer.
I'd be interested in more examples of using Failure, particularly P5 vs. P6.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
If you give me some ideas, I might elaborate on them.
| [reply] |
You gave several examples of P5 error checking, but didn't give the P6 version(s). Also, isn't there a way of telling the Failure object why the failure happened?
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
You might add an example for the infix:<orelse> operator, which seems to be also designed for handling undefs and failures, but which I don't really understand yet ;-) | [reply]
[d/l] |
Small nit. err was dropped sometime after 5.9.3, wasn't it?
Still, another excellent article. ++ | [reply] |
I'm not sure. I made a note to change err to orelse, but I want to hear back from P6 mailing list first for the real story.
| [reply] |
Your set-inclusion line seems to be inverted to me. I would write:
unhandled failures⊂ failures⊂ undefs⊂ falses
That is to say, "the set of unhandled failures is a proper subset of the set of failures, that is a proper subset of the set of undefined values, that is a proper subset of false values".
Because "" is a false value, but none of the others, undef is an undefined value and a false value but none of the others, etc...
[]s, HTH, Massa (κς,πμ,πλ)
| [reply]
[d/l]
[select] |