Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] Static exception analysis or alternative to using exceptions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Florent Ouchet <florent.ouchet@i...>
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions

In VSYML [1], the exception Not_found was raised deep in the code in 
some functions from List and in some redefined functions (such as 
ocamlutils_find_assoc with a custom key comparer). This project can be 
assimilable to a code compiler or a code interpreter where these 
functions are called during the syntax tree conversion.

There is not "real" problem when the exception is caught at an higher 
level but when the exception is not caught at the "deep-1" level, the 
user will likely receive the wrong error message and this error will 
likely be reported at the wrong position in the VHDL source file. That 
was just disturbing and it required some "tact" to find the exact problem.

In version VSYML 1.7, I switched from exception to optional result and 
the application is more stable. By using optional result, the required 
pattern matching ensures the error handling at the deep-1 level.

[1] VSYML: VHDL Symbolic Simulator in OCaml 
http://users-tima.imag.fr/vds/ouchet/vsyml.html

- Florent

Eray Ozkural a écrit :
> On Thu, May 27, 2010 at 11:08 AM, Florent Ouchet <florent.ouchet@imag.fr> wrote:
>   
>> Hello,
>>
>> Same here, specially to avoid the Not_found exception.
>> The optional return values gives the oportunity to have a clear view of what
>> is being done if the result is not available.
>>     
>
> That depends on the code, I think. In some cases the exception may
> arise from deep in the code, and it would make sense not to bother
> with a lot of type overhead for many levels of nesting and function
> calling. But if all you are doing is checking the success of a
> function, I suppose option types will be more efficient.
>
> Best,
>
>   


-- 
Florent Ouchet
PhD Student
CIS/VDS Team - TIMA Laboratory