From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA24046; Thu, 15 Jul 2004 14:49:22 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA22982 for ; Thu, 15 Jul 2004 14:49:21 +0200 (MET DST) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.242]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i6FCnJSH021765 for ; Thu, 15 Jul 2004 14:49:20 +0200 Received: by mproxy.gmail.com with SMTP id w29so1138165cwb for ; Thu, 15 Jul 2004 05:49:19 -0700 (PDT) Received: by 10.11.116.22 with SMTP id o22mr56100cwc; Thu, 15 Jul 2004 05:49:19 -0700 (PDT) Message-ID: <7f8e92aa04071505495315454@mail.gmail.com> Date: Thu, 15 Jul 2004 15:49:19 +0300 From: Radu Grigore To: caml-list@inria.fr Subject: Re: [Caml-list] assertions or exceptions? In-Reply-To: <20040715101826.GA10062@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7f8e92aa04071501035091cbe9@mail.gmail.com> <20040715101826.GA10062@redhat.com> X-Miltered: at concorde with ID 40F67D4F.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 assertion:01 advocated:01 msdn:01 2004:99 assertion:01 extlib:01 reinventing:01 nonetheless:01 bool:01 ocaml:01 null:01 null:01 assertions:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 15 Jul 2004 11:18:26 +0100, Richard Jones wrote: > [...] But in > many cases, the underlying C fields being NULL is an internal error > for which we are not prepared, and the only sensible thing to do then > is not to force people to deal with it locally, but to throw an > exception which causes the whole script/program to fail. You say that the only sensible thing to do is for the program to fail. But that's what assertions (not exceptions) are for. So why don't you assert when the C string is NULL? I see couple of reasons: (1) without knowing the client code you can't be sure it's an internal error and (2) you want to give the client a chance to fail gracefully (ie. save any state that might be useful to the user, inform the user, etc.). The first reason does not hold for internal/private functions, ie. those functions that have clients which are under your control. Would you use an assertion for such a function? Or you never use assertions? Note that in your example there is always a third choice (the one advocated by .NET class library design guidelines): do what you do but also provide a function Request.valid_hostname : Request.t -> bool You might argue that the end result is the same for the client. With your solution a client that does not expect a failure does not write a try block, while one that knows it's OK to fail from time to time will use a try block. The problem is that you force the client to use an exception in circumstances that are _not_ exceptional from his point of view. So giving him the option of saying "if valid_hostname then I don't expect this to fail" is a plus. See: http://blogs.msdn.com/cyrusn/archive/2004/06/16/156865.aspx for another discussion along these lines. BTW, I think that the solution you have chosen in this case is the right one. I'm just trying to find some guidelines, which work most of the time, of when to use an exception versus an assertion. The best I've found so far is the advice from Sun to use exceptions for checking preconditions of public methods and assertions everywhere else. I'd go one step further and say that exceptions should be used only in the public interface of a component (which is not the same as a class -- especially for a language like OCaml :) ). You said nothing about assertions. You don't use them? > > 3. Is it possible to avoid using exceptions and read a text file > > line-by-line until EOF? > > There are functions in ExtLib to do this, I think. If not then you > should write a function like 'input_all_lines' or 'iter_over_lines f' > once, put it into a small local library, and use it every time. No > point reinventing wheels each time. Ok, so I can hide the usage of the exception. It doesn't make me feel much better. It feels more like redesigning the interface of the standard library. (but it's a good idea nonetheless). regards, radu ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners