Hi,
> What experience does people have to using alternatives to exceptions,
> such as option types or exception monads? Does use of third part
> libraries that still throws exceptions make such approaches hard to use?
> Performance wise it seems to be comparable to catching exceptions or
> matchin
On Wed, May 26, 2010 at 7:30 PM, Dario Teixeira wrote:
> Hi,
>
> > What experience does people have to using alternatives to exceptions,
> > such as option types or exception monads? Does use of third part
> > libraries that still throws exceptions make such approaches hard to use?
> > Performance
Jane Street's Core seems to prefer options to exceptions
On Wed, May 26, 2010 at 5:10 PM, Hans Ole Rafaelsen wrote:
>
>
> On Wed, May 26, 2010 at 7:30 PM, Dario Teixeira
> wrote:
>
>> Hi,
>>
>> > What experience does people have to using alternatives to exceptions,
>> > such as option types or e
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.
- Florent
Jacques Le Normand a écrit :
Jane Street's Core seems to prefer options to exceptions
On Wed, Ma
On Thu, May 27, 2010 at 11:08 AM, Florent Ouchet 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 cas
Florent Ouchet wrote:
> 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.
Agreed - though [find] is one of the examples where you do need find and
find_exc - because
On Thu, May 27, 2010 at 09:54:29AM +0100, David Allsopp wrote:
> Florent Ouchet wrote:
> > 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.
>
> Agreed - though [
> Agreed - though [find] is one of the examples where you do need find and
> find_exc - because often there are occasions where before calling
> {Map,Set,Hashtbl}.find you already know that the key exists and so won't
> fail at which point the 'a option boxing is a waste of time and space and
> Not
Daniel Bünzli wrote:
> > Agreed - though [find] is one of the examples where you do need find
> > and find_exc - because often there are occasions where before calling
> > {Map,Set,Hashtbl}.find you already know that the key exists and so
> > won't fail at which point the 'a option boxing is a wast
Mark Shinwell wrote:
> On Thu, May 27, 2010 at 09:54:29AM +0100, David Allsopp wrote:
> > Florent Ouchet wrote:
> > > 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 av
Hi,
If you're interested, three of us on this mailing-list wrote a paper on the
topic two few years ago [1].
Best regards,
David
[1] _Catch me if you can Looking for type-safe, hierarchical, lightweight,
polymorphic and efficient error management in OCaml_,
http://en.scientificcommons.org
On 05/26/2010 06:15 PM, Hans Ole Rafaelsen wrote:
What experience does people have to using alternatives to exceptions,
such as option types or exception monads? Does use of third part
libraries that still throws exceptions make such approaches hard to use?
Performance wise it seems to be compara
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 d
On Wed, May 26, 2010 at 11:37 PM, Jacques Le Normand
wrote:
> Jane Street's Core seems to prefer options to exceptions
>
Batteries also includes a number of Exceptionless modules (ex.
Array.Exceptionless) which wrap exception-raising functions to use
options instead.
On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
> What experience does people have to using alternatives to exceptions, such
> as option types or exception monads? Does use of third part libraries that
> still throws exceptions make such approaches hard to use? Performance wise
Hi,
> Personally I've found that you should only throw those exceptions
> which can be caught in a single place in the program. By this I mean
> that an exception such as Not_found shouldn't be thrown, and instead
> it would be better to use an option type (for stdlib functions which
> throw Not_
Richard Jones writes:
> On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
>> What experience does people have to using alternatives to exceptions, such
>> as option types or exception monads? Does use of third part libraries that
>> still throws exceptions make such approaches h
Goswin von Brederlow a écrit :
Imho a good module should provide both an exception and option based
interface to fit the circumstances and programming style.
+1
It would be nice if the possible exceptions of a function would be part
of the type. E.g.
let f1 () = raise Not_found
val f1 : u
Goswin von Brederlow wrote:
> > However if the exception is, say, an I/O error reading a disk file,
> > these should be thrown, and caught somewhere central where you can
> > display an error message to the user (for GUI programs) or abort the
> > current transaction (for server programs). Recove
On Mon, 31 May 2010 16:36:22 +0200, Goswin von Brederlow
wrote:
> Richard Jones writes:
>
> > On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
> >> What experience does people have to using alternatives to exceptions, such
> >> as option types or exception monads? Does use of
> It would be nice if the possible exceptions of a function would be part
> of the type. E.g.
>
> let f1 () = raise Not_found
> val f1 : unit -> 'a [ Not_found ]
>
> let f2 () = try f1 () with Not_found -> ()
> val f2 : unit -> unit
>
> let f3 f = try f () with Not_found -> ()
> val f3: (unit -> '
On 05/31/2010 08:24 PM, David Allsopp wrote:
> Goswin von Brederlow wrote:
>
>>> However if the exception is, say, an I/O error reading a disk file,
>>> these should be thrown, and caught somewhere central where you can
>>> display an error message to the user (for GUI programs) or abort the
>>> c
On Mon, May 31, 2010 at 9:30 PM, Nicolas Pouillard
wrote:
>
> Since having all functions in all flavours can lead to hard to interface
> bloat, one should consider tiny functions to switch from a style to another.
> It tends to be easier to start from an option type in the case of Not_found
> inst
> I use a syntax extension that catches "Not_found" and raises a failure
> instead, with the source location of the "real" offending call. I do
> this mostly because OUnit catches exceptions so backtraces are of no
> use.
I have encoutered the same problem and resolved it with explicit
backtrace h
Richard Jones wrote:
"... All in all, this is not ideal for writing correct programs. Some sort
of exception analysis would be most welcome."
Doesn't the "catch me if you can" library provide this?
Among the listed features are:
* case coverage (i.e. the compiler can tell you if you forgot a
"David Allsopp" writes:
> Goswin von Brederlow wrote:
>
>> > However if the exception is, say, an I/O error reading a disk file,
>> > these should be thrown, and caught somewhere central where you can
>> > display an error message to the user (for GUI programs) or abort the
>> > current transact
26 matches
Mail list logo
