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