From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id D7A4CBBAF for ; Mon, 31 May 2010 22:51:50 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIBAOC9A0zRVaE0mGdsb2JhbACeIggVAQEBAQEICQwHESKvLIIChSAuiE8BAQMFhREEg0M X-IronPort-AV: E=Sophos;i="4.53,335,1272837600"; d="scan'208";a="52158370" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail2-smtp-roc.national.inria.fr with ESMTP; 31 May 2010 22:51:50 +0200 Received: by fxm19 with SMTP id 19so2617941fxm.39 for ; Mon, 31 May 2010 13:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Bdyhyaak8h0ehnjLZP39t00ZaZ8ABZmsY+IFsf0tokQ=; b=ZXrsxfmntCP/VWMGhK29a6q/BNn6PDHCzOvtM78RU1kknBmD820yMiDZEPn/8LJYir 6S/dDm/fYlF+pyxgbFXRJwRW4UK79XiWemfFSkae3jVZBap/HiYgZ5grielIdxORhf9+ 6+f0TZRhDa7G1yAJskVlFMeLTnvyQrt0dGEMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=SnU6SzNRW6NjySD9ZEdBhtx6IY9O6qsCZlg9ztgpyXxSJoAayIyJEyuYv7YRlL56Dx ojXzQLD+NUAFwACWaOiI1VHDgnmk6eUA7pvQqjoL7y/IIx8XNF9n6nGglk49dekSeRPN cpkTfTp5y3CIYByG2SnRy8N7yQQETvzncoSE8= Received: by 10.223.54.140 with SMTP id q12mr5944704fag.50.1275339110279; Mon, 31 May 2010 13:51:50 -0700 (PDT) Received: from debian ([79.114.38.162]) by mx.google.com with ESMTPS id 15sm43384797fad.10.2010.05.31.13.51.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 May 2010 13:51:48 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by debian (Postfix) with ESMTP id 60C1F15FF32 for ; Mon, 31 May 2010 23:51:47 +0300 (EEST) Message-ID: <4C042162.4010103@gmail.com> Date: Mon, 31 May 2010 23:51:46 +0300 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions References: <20100527170122.GA28273@annexia.org> <87y6f0cf4p.fsf@frosties.localdomain> <002c01cb00e6$20bfcd30$623f6790$@romulus.metastack.com> In-Reply-To: <002c01cb00e6$20bfcd30$623f6790$@romulus.metastack.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=5379965D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 lacks:01 impl:01 'open:01 'open:01 val:01 val:01 ocamlexc:01 ocaml:01 compiler:01 compile-time:01 bug:01 edwin:98 .....:98 wrote:01 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 >>> current transaction (for server programs). Recovering from such >>> exceptions properly is still tricky though. Since OCaml lacks >>> 'finally', you either have to use a 'finally' impl from a library, or >>> modify your code to not need it (eg. turning calls to 'open_in' and >>> 'open_out' into a kind of continuation-passing style). Or for small >>> programs, abort the program and don't deal with recovery at all. >>> >>> All in all, this is not ideal for writing correct programs. Some sort >>> of exception analysis would be most welcome. >> >> 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 -> 'a [< Not_found >> | 'B ]) -> 'a [ 'B ] >> >> and so on. >> >> >> Someone would have to write a new type system for that though. > > Would it be more practical to have that analysis as part of the .annot file? > Presumably a patch which merged and updated the codebase of ocamlexc to > produce exception-annotations in that manner might have a chance of making > it into the OCaml compiler itself. I'm guessing that what you're getting at > is the ability to see from your code that an exception could escape at any pattern-match like exhaustive check that all cases are covered could be useful. try ... with Not_found -> ... error: exception catch clause is not exhaustive, exceptions not covered: ..... Maybe using a separate keyword, or a compile-time flag for this? > given point rather than trying to add Java-style "checked exceptions" to > OCaml? > I think there are 2 things to watch out when looking at Java and exceptions: - if a function throws too many exceptions, you sometimes see things like "throws Exceptions", or "catch (Exception e) { // ignore }" in Java code, which are completely useless, and might even lead to bugs (silently ignoring all exceptions) - throwing an exception when a lookup doesn't find something is not always the best. Look at Java's class loader which throws an exception when a class is not found (pretty common when loading plugins) instead of returning null. I think that lookup functions should come in 2 flavours: - one that doesn't use exceptions (uses option types), for example 'find'. The key you are looking for may or may not be there - one that uses exceptions, for example 'get'. You know that the key is there (or should be there), and you want the value. If the key isn't there its probably a bug, or a very rare condition so the exception is good here. I think the exception variant could even be generated automatically as a wrapper to the option variant (not viceversa) Best regards, --Edwin