Hi,
I benchmarked two programs, in one case the main function throw an
exception that is caught, in the other the function returns an option that
is pattern matched on.
I noticed that, whether the exception is thrown or not, the option version
is always faster.
Is there any case where it makes s
When thinking about performance, consider the "try" keyword to take time
to execute. A try block pushes an exception handler onto a stack and
pops the stack on exit. The try block may also interfere with tail call
optimizations.
A loop like
for i = 0 to 1000 do try ... done
executes "tr
2 more use cases:
1) When writing a deep recursion
Throwing an exception will directly jump to your "catch" block without
having to unfold every return call site on the stack one by one. Which can
be much faster if the recursion is very "deep".
2) When your exception is exceptional :-)
If Not_fou
I think there was an article about options versus exceptions
in the OCaml journal.
If I remember well, the exceptions were faster, but I can't
find back the exact benchmark and context of this assertion.
Regards,
F.
On 04/05/2012 07:10 AM, Julien Verlaguet wrote:
2 more use cases:
1) When wri
Aside from performance considerations, there are semantics differences
to take into account. This blog post explain why exceptions are
"better" (or, more precisely, why it is not generally a good idea to
replace exceptions by options)
http://blog.dbpatterson.com/post/9528836599 (it is in Haskell ra
That post is against maybe (aka option) as an error type as it looses
information about the error. If you use an Either type such as Core's
Result.t that argument is invalidated.
In fact at Jane Street we try avoid the use of exceptions as they don't
force the client of the library to handle the
Pierre Chopin writes:
> Hi,
>
> I benchmarked two programs, in one case the main function throw an exception
> that is caught, in the other the function returns an option that is pattern
> matched on.
>
> I noticed that, whether the exception is thrown or not, the option version is
> always faste
Le jeudi, 5 avril 2012 à 11:05, Goswin von Brederlow a écrit :
> If you are writing a module then consider providing both flavours for
> functions, one with exceptions and one with options. Even if you only do
> something like this:
I don't think it's a rule that should be applied consistently, I
Thank you for your answers.
I am actually in the case of a webserver where I need to avoid interrupting
it, even in 'exceptional' cases, but rather report the problem in a log,
and return a default value whenever it is possible. Options seem to be the
best choice, not only from a safety point of vi
Daniel Bünzli writes:
> Le jeudi, 5 avril 2012 à 11:05, Goswin von Brederlow a écrit :
>> If you are writing a module then consider providing both flavours for
>> functions, one with exceptions and one with options. Even if you only do
>> something like this:
>
>
> I don't think it's a rule th
On Wed, Apr 11, 2012 at 11:26 AM, Goswin von Brederlow
wrote:
>> However in the particular case of finding something in a data structure
>> where the user could be confronted with a situation where he can prove that
>> the datum will be found I think it's justified to provide both flavours. For
On Wed, Apr 11, 2012 at 11:32 AM, David House wrote:
> On Wed, Apr 11, 2012 at 11:26 AM, Goswin von Brederlow
> wrote:
>>> However in the particular case of finding something in a data structure
>>> where the user could be confronted with a situation where he can prove that
>>> the datum will b
12 matches
Mail list logo
