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 CAA21802; Wed, 19 Nov 2003 02:34:26 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA21891 for ; Wed, 19 Nov 2003 02:34:24 +0100 (MET) Received: from mail.dcs.qmul.ac.uk (vicar.dcs.qmul.ac.uk [138.37.88.163]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hAJ1YO115515 for ; Wed, 19 Nov 2003 02:34:24 +0100 (MET) Received: from xenografia.plus.com ([212.159.85.26] helo=dcs.qmul.ac.uk) by mail.dcs.qmul.ac.uk with asmtp (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.24) id 1AMHEd-00059I-Ce; Wed, 19 Nov 2003 01:34:23 +0000 Message-ID: <3FBAC880.9040903@dcs.qmul.ac.uk> Date: Wed, 19 Nov 2003 01:33:52 +0000 From: Martin Berger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benjamin Geer CC: Caml Mailing List Subject: Re: [Caml-list] GC and file descriptors References: <1069168323.18363.83.camel@pelican> <3FBA4D97.9060309@dcs.qmul.ac.uk> <3FBA6459.3000000@socialtools.net> In-Reply-To: <3FBA6459.3000000@socialtools.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Auth-User: martinb X-DCS-Spam-Score: -2.5 X-clamav-result: clean (1AMHEd-00059I-Ce) X-uvscan-result: clean (1AMHEd-00059I-Ce) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 stones:99 subtypes:01 subtypes:01 subtyping:01 subtyping:01 imprecise:01 hierarchies:01 descriptors:01 handles:01 exception:02 exception:02 objects:02 nested:02 nested:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > From experience working on fairly large programs in Java, I can say (at > the risk of being pelted with stones on this list) that I think the way > Java handles this works pretty well. You can avoid having any methods > specify more than two or three exceptions by using hierarchies of > exception subtypes (e.g. IOException has subtypes FileNotFoundException, > SocketException and so on) and by using nested exception objects (e.g. a > FooSubsystemException can contain an instance of any other exception, > and can thus be handled by a method that only specifies > FooSubsystemException). my (limited) experience with java suggests that in large projects one of the following happens: * all exceptions specs are written out in detail (ie no grouping using subtyping etc). in this case, way too much code is nothing but exception specs. * the subtyping approach is used. in this case exception specifications are too imprecise; * something that seems like what you refer to as nested exceptions where you catch exceptions at every layer and convert them into some other exception. in this case you litter the code with catch statements that seem superflouos. in summary, i do not recommend the java approach (for other reasons too, like unchecked exceptions). i think exception specification polymorphism is cruical. maybe some other ideas are also needed. martin ------------------- 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