From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id B51A67F8F3 for ; Tue, 27 May 2014 11:26:02 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of nicolas.boulay@gmail.com) identity=pra; client-ip=209.85.223.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="nicolas.boulay@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of nicolas.boulay@gmail.com designates 209.85.223.173 as permitted sender) identity=mailfrom; client-ip=209.85.223.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="nicolas.boulay@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f173.google.com) identity=helo; client-ip=209.85.223.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="postmaster@mail-ie0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiACAHRZhFPRVd+tlGdsb2JhbABZg1lYgmqpU4EHi1SIfIEHCBYOAQEBAQcLCwkSKoIlAQEBAwESEQQZAQYnCwEDAQsBBQULGh0CAiISAQUBChIGExIQiAwDCQgNoyhqiyeEfzWYcycDCoYaEQEFDIknhRuDAIFLBIReBZUQgT2PeRgpgWmDATs X-IPAS-Result: AiACAHRZhFPRVd+tlGdsb2JhbABZg1lYgmqpU4EHi1SIfIEHCBYOAQEBAQcLCwkSKoIlAQEBAwESEQQZAQYnCwEDAQsBBQULGh0CAiISAQUBChIGExIQiAwDCQgNoyhqiyeEfzWYcycDCoYaEQEFDIknhRuDAIFLBIReBZUQgT2PeRgpgWmDATs X-IronPort-AV: E=Sophos;i="4.98,917,1392159600"; d="scan'208";a="64308275" Received: from mail-ie0-f173.google.com ([209.85.223.173]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 May 2014 11:26:01 +0200 Received: by mail-ie0-f173.google.com with SMTP id lx4so8500005iec.4 for ; Tue, 27 May 2014 02:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mTMSaDVLI7cl5XUgrPhWRRIbX1lv1ZGXwGG+Lm09AbU=; b=IYjgG0s+FoqnyowuP0YB0jEd6IESJLawQbiY/SGLfXpb76GQLSNxg+ondnwI38VIDs yhyg7yYwpaB5NAIODeHZ0jfzSM18NdXcQ8nMxEp6AC/2qndaNwxu6I2tbLdXEXSola2W A9jSJPyj3jriQE8fiLuUm0KSKb5Kp1FxWM1Sp8hUIYQmfb5oKp8VIug/r3tMwSAt2qjb iQIb0sRgiHdDxS8GGmzQX0BeoL14eSktUFT15NnZl1U53e4tRbGHa33FiL05lt4G6rGi sMMWImENMGrMvQTux/MVMz6ooEQxcqU67B3RyXYORbd4OxPSHw89tA5qTZoydgTOgX8p HjyQ== MIME-Version: 1.0 X-Received: by 10.50.137.67 with SMTP id qg3mr31136069igb.33.1401182759973; Tue, 27 May 2014 02:25:59 -0700 (PDT) Sender: nicolas.boulay@gmail.com Received: by 10.50.50.135 with HTTP; Tue, 27 May 2014 02:25:59 -0700 (PDT) In-Reply-To: <53B801AD6F5B4BFBA0DA2A69D8775497@erratique.ch> References: <53835610.9050609@inria.fr> <53B801AD6F5B4BFBA0DA2A69D8775497@erratique.ch> Date: Tue, 27 May 2014 11:25:59 +0200 X-Google-Sender-Auth: oOjgY6idFQw8V7azwpew4CXSAlw Message-ID: From: Nicolas Boulay To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: Philippe Veber , Ben Millwood , Romain Bardou , caml users Content-Type: multipart/alternative; boundary=001a11c3de38ac787904fa5e4844 X-Validation-by: nicolas@boulay.name Subject: Re: [Caml-list] Uncaught exceptions in function type. --001a11c3de38ac787904fa5e4844 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2014-05-26 18:34 GMT+02:00 Daniel B=C3=BCnzli : > Le lundi, 26 mai 2014 =C3=A0 18:02, Philippe Veber a =C3=A9crit : > > Thanks! BTW core still uses exceptions. Is there an explicit rule as to > how to decide between Result type or exceptions. For instance, why not > write the Array.create function like this: > > > > val create : int -> 'a -> 'a array Or_error.t > > > > where create fails for a negative integer? > Because that would be utterly annoying. You need to make the following > distinctions: > > Yes it could be annoying, but very high quality software become much harder to write. Refactoring is harder. Missing exception handler are harder to find. > * Programming errors, for contracts with the programmer that cannot be > enforced through types. For that raises Invalid_argument if the contract = is > violated. Invalid_argument is not supposed to be handled, it denotes an A= PI > misuse, like calling Array.create with a negative integer. > > * Exceptional errors, for errors that the programmer is unlikely to handle > at all (e.g. out of memory). For that raise a custom exception. This shou= ld > occur very rarely, you are unlikely to ever define one such exception. > > That means intensive testing to be sur to avoid such failure for normal user input. For most long running programme (server, gui), that's could a problem. For example, an undo/redo use lot of memory after some copy/paste on big data, then the save command have not enough memory to work, and the file are troncated. That's not acceptable, and can be see only with big data, after few high level command run. Regards, Nicolas > * Non-exceptional errors, errors that the programmer will have to handle > (e.g. failing to connect a socket), for that do not use a custom exception > but use variants or options types. > > In general if you write libraries it=E2=80=99s better to err on the side of > exceptionless design: never use exceptions beyond Invalid_argument (and > especially never use Not_found or Failure). Leave exception > definition/usage at the discretion of the user (if he wishes to shoot > himself in the foot). > > Best, > > Daniel > > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a11c3de38ac787904fa5e4844 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



2014-05-26 18:34 GMT+02:00 Daniel B=C3=BCnzli <= ;daniel.bu= enzli@erratique.ch>:
Le lundi, 26 mai 2014 =C3= =A0 18:02, Philippe Veber a =C3=A9crit :
> Thanks! BTW core still uses exceptions. Is there an ex= plicit rule as to how to decide between Result type or exceptions. For inst= ance, why not write the Array.create function like this:
>
> val create : int -> 'a -> 'a array Or_error.t
>
> where create fails for a negative integer?
Because that would be utterly annoying. You need to make the followin= g distinctions:


Yes it could be annoying, but very hig= h quality software become much harder to write. Refactoring is harder. Miss= ing exception handler are harder to find.
=C2=A0
* Programming errors, for contracts with the programmer that cannot be enfo= rced through types. For that raises Invalid_argument if the contract is vio= lated. Invalid_argument is not supposed to be handled, it denotes an API mi= suse, like calling Array.create with a negative integer.

* Exceptional errors, for errors that the programmer is unlikely to handle = at all (e.g. out of memory). For that raise a custom exception. This should= occur very rarely, you are unlikely to ever define one such exception.

That means intensive testing to be sur to avoid such = failure for normal user input. For most long running programme (server, gui= ), that's could a problem.

For example, an undo/redo = use lot of memory after some copy/paste on big data, then the save command = have not enough memory to work, and the file are troncated. That's not = acceptable, and can be see only with big data, after few high level command= run.

Regards,
Nicolas
=C2=A0
* Non-exceptional errors, errors that the programmer will have to handle (e= .g. failing to connect a socket), for that do not use a custom exception bu= t use variants or options types.
=C2=A0
In general if you write libraries it=E2=80=99s better to err on the side of= exceptionless design: never use exceptions beyond Invalid_argument (and es= pecially never use Not_found or Failure). Leave exception definition/usage = at the discretion of the user (if he wishes to shoot himself in the foot).<= br>
Best,

Daniel



--
Caml-list mailing list. =C2=A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--001a11c3de38ac787904fa5e4844--