Circle Calculator Help

bearophile bearophileHUGS at lycos.com
Tue Jun 26 16:10:25 PDT 2012


Steven Schveighoffer:

> I agree with Andrei, there is no outlet for errors in the to!T 
> function, exception is the logical choice.

Maybe I was not clear enough, so let me explain a bit better.

What I don't like is to!int("15\n") to be seen as an error in the 
first place.
I'd like it to ignore leading and trailing whitespace, as in 
Python (stripping it automatically):

>>> int("15\n")
15

So it's not a matter of ignoring the errors, but ignoring that 
leading and trailing whitespace.

On the other hand, if you write   to!dstring("15\n")  this 
shouldn't strip away whitespace :-) So I understand Andrei 
motives too. To do that you have to hard-code different behaviors 
inside to!() according to the destination type. This is not so 
good.


> But I also agree with you that if you don't care, it should be 
> possible to ignore the errors without the cumbersome try-catch 
> mechanism.  Something like:
>
> to!(float, throw.No)(a)
>
> or
>
> toNoThrow!float(a)

What is it doing if you give it a wrong input string 'a'?

This seems useful, but as you have seen it's different from what 
I was looking for.

A non-throwing to!() may be handy to have:

nullableTo!int("XX") => empty Nullable

Nullable.get() is able to throw an exception. If you handle both 
empty and full cases of a nullable the D compiler is not able to 
statically infer that your code can't throw. You have to wrap 
that code into catching instructions any way, if you want your 
whole function (that uses nullableTo) to be nonthrow.

Bye,
bearophile


More information about the Digitalmars-d-learn mailing list