Benchmark of try/catch

[dsimcha]

== Quote from grauzone (none at example.net)'s article
> Using exceptions in a string->int conversion routine is really horrible
> and incredibly stupid. It raises all these issues, just because you
> can't signal failure in a better way. For parsing input, failure should
> be something to be _expected_, not an _exception_. You always want to
> check for success, but you don't force the programmer to check; instead,
> you'll make it harder by requiring the programmer to add this awkward
> try-catch thing around the function call.
> There are some more things one could criticize, and possible solutions
> one could discuss (like reviving checked exception in a non-sucky
> version), but I'll stop now.
> /rant

For what it's worth, to me the whole point of exceptions is that they're for
things that the immediate caller might not have a good answer for.

The ideal test of whether you should be using exceptions or something else is
whether it would be reasonable for the immediate caller of some function to ignore
the error condition and let it bubble up.  Checked exceptions defeat this because
they require the caller of a function to do _something_ even if they can't
actually do anything useful.  In your string->int conversion example, it's
perfectly reasonable that the caller of int() might have no idea what a reasonable
course of action would be if the conversion fails and would want to pass the buck
to its caller.  Therefore, exceptions are a perfectly reasonable way to handle this.

One thing that would be nice is if ddoc could automatically document what
exceptions every function throws when generating documentation.  Of course, there
would be the problem of dealing with libraries for which the source code isn't
available, but in a lot of cases, this would be feasible and very useful.