From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 23EF0BC57 for ; Thu, 27 May 2010 11:34:39 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAGbZ/UvB/Bd4dWdsb2JhbACeGBUBFyAFH8AhhRME X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; d="scan'208";a="60121741" Received: from smtp-msa-out01.orange.fr ([193.252.23.120]) by mail1-smtp-roc.national.inria.fr with ESMTP; 27 May 2010 11:34:38 +0200 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf5a04.orange.fr (SMTP Server) with ESMTP id 53CF71C00617; Thu, 27 May 2010 11:34:38 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf5a04.orange.fr (SMTP Server) with ESMTP id 3FA071C00944; Thu, 27 May 2010 11:34:38 +0200 (CEST) Received: from [192.168.1.90] (APuteaux-154-1-15-28.w83-199.abo.wanadoo.fr [83.199.16.28]) by mwinf5a04.orange.fr (SMTP Server) with ESMTP id E5B591C00617; Thu, 27 May 2010 11:34:37 +0200 (CEST) X-ME-UUID: 20100527093437941.E5B591C00617@mwinf5a04.orange.fr X-ME-User-Auth: lexifi Message-ID: <4BFE3CAE.9090107@frisch.fr> Date: Thu, 27 May 2010 11:34:38 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hans Ole Rafaelsen Cc: caml-list@inria.fr Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 rafaelsen:01 monads:01 runtime:01 encapsulated:01 variants:01 exn:01 ocaml:01 polymorphic:01 wrote:01 stack:01 extensible:01 exception:01 exception:01 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 comparable to catching exceptions or > matching for options, so I guess the difference be might a question of > programming style? Indeed, this is mostly a matter of taste and style. My personal "Rule #1" to decide to use exceptions or not is that one: Raising an exception is ok if you know where it will be caught or which global effect it will have on the application. This includes the following cases: - (Short jumps) Using exceptions locally as shortcuts in loops or more complex algorithms. In that case, the runtime exception is encapsulated in a function or module, and should not cause any harm. - (Long jumps) Using exceptions to report unexpected errors, to which the application has little chance to react in a clever way except displaying some error messages to the screen or to a log file. The catch point is a global exception handler, even though the code raising the exception (maybe in a general purpose library) might not know exactly how the application will react to the exception. It is much better if the exception describes the problems in terms that can be understood by a human (Not_found, even with a stack trace, is not very helpful as an error message). Library function that perform some kind of lookup should return an option type and let the caller raise a proper exception to report error in a way that makes sense for the application. Similarly for other kind of functions that can "fail": use a sum type (or polymorphic variants) instead to describe the possible "errors". A variant of the function that raises an exception is acceptable for cases where the caller really expect the function to succeed (it can fail only because of bugs in the application, not because of user or system errors). In that case, Assert_failure, or a custom exception, is probably better than Not_found. More generally, if exceptions are to be used, custom ones are usually better than generic ones (Failure, Invalid_argument). Another interesting use of exceptions comes from the fact that exn is an extensible sum type. (Unfortunately, it is the only one in OCaml.) This enables some kinds of loosely typed scenarios, like notification messages to be dispatched across global objects in the application: the list of possible messages is not fixed in advance, and each object can simply use pattern matching to react on messages it is interested in. But this is another story... Alain