Browse thread
Re: [Caml-list] Static exception analysis or alternative to using exceptions
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-05-27 (11:10) |
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