Benchmark of try/catch

[Daniel Keep]

> I only had a short look, is it the NaN known from floating point types
> generalized to all types?

Not quite; NaNs don't abort your program (ignoring signalling NaNs, of
course.)

> Yay, The Power of None! That's what I was referring to when proposed
> nullable types:
> 
> int? value1 = atoi("0");   // 0
> int? value2 = atoi("#!$"); // null

Not quite; that assumes null isn't a valid value.  What if the function
was "getInstance"?

Here's how I understand it to work.  Functions may return a Maybe!(T),
which is either a T or None (note that None is not null), and is
implicitly castable to T.

Now, let's say we have this:

Maybe!(int) toInt(string);

Suppose we have the following:

void main()
{
    writef("Enter a number: ");
    string num_str = readline();
    auto result = toInt(num_str);
    int num = result;
    writefln("You entered: %d", num);
}

Now, when the program asks for a number, we enter "42".  The program
works exactly as one would expect; no drama.  The Maybe!(int) is
transparently cast to an int.

Next we try entering "get nodded" instead.  toInt doesn't take kindly to
this, and wants to throw an InsultingInputException.  However, it
doesn't actually throw it; it merely constructs the exception and
returns it inside a None value.

So in this case, result is a Maybe!(int) containing a None, wrapping an
Exception.  This is fine.  It's not until the program tries to cast the
result to an int that the exception is thrown.  That is, the exception
is only thrown at the moment we attempt to USE the result and find it's
not valid.

Alternately, we could do this:

void main()
{
    writef("Enter a number: ");
    string num_str = readline();
    auto result = toInt(num_str);
    if( result == None )
    {
        writefln("Error: \"%s\" is not a number.", num_str);
    }
    else
    {
        int num = result;
        writefln("You entered: %d", num);
    }
}

We can directly test a Maybe!(T) to see if it's None; this allows us to
safely work out whether the function failed or not.

The idea behind all this is to allow for exception-style programming
where we don't care about testing for failures (but still want them to
stop our program via an exception) OR C-style programming where we DO
care about a particular function failing, and test the return values.

The nice thing about this is that you either explicitly test for and
handle the error, or it jumps out at you like a spider if you try to
ignore it -- best of both worlds without the risk of missing a failure.

  -- Daniel