expectations 0.1.0
Paul Backus
snarwin at gmail.com
Mon Sep 3 03:23:43 UTC 2018
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev
wrote:
> Please correct me if I'm wrong, but from looking at the code,
> given e.g.:
>
> Expected!void copyFile(string from, string to);
>
> nothing prevents me from writing:
>
> void main() { copyFile("nonexistent", "target"); }
>
> The success value is silently discarded, so we end up with a
> "ON ERROR RESUME NEXT" situation again, like badly written C
> code.
This is definitely a big weakness of `Expected!void`, and one I
hadn't considered when writing the code. With a normal
`Expected!T`, the fact that you care about the return value is
what forces you to check for the error, but that doesn't apply
when the return value is `void`.
I'm not sure at this point if it's better to leave
`Expected!void` in for the sake of completeness, or remove it so
that nobody's tempted to shoot themself in the foot. Definitely
something to think about.
> One way we could improve on this in theory is to let functions
> return a successfulness value, which is converted into a thrown
> exception IFF the function failed AND the caller didn't check
> if an error occurred.
>
> Draft implementation:
>
> struct Success(E : Exception)
> {
> private E _exception;
> private bool checked = false;
> @property E exception() { checked = true; return _exception; }
> @property ok() { return exception is null; }
> @disable this(this);
> ~this() { if (_exception && !checked) throw _exception; }
> }
This is a really clever technique. As you said, hard to say
whether it's worth it compared to just throwing an exception
normally, but still, really clever.
More information about the Digitalmars-d-announce
mailing list