Path: news.cs.au.dk!not-for-mail From: nospam2159@cs.au.dk (Peter von der =?iso-8859-1?q?Ah=E9?=) Newsgroups: comp.lang.beta Subject: Re: Static vs. dynamic exceptions Date: 21 Jun 2000 02:03:59 +0200 Organization: Computer Science Department of the University of Aarhus Lines: 32 Message-ID: References: <20000619173848.8485.qmail@noatun.mjolner.dk> <8im02p$8s5j$1@xinwen.cs.au.dk> <8infta$9jn7$1@xinwen.cs.au.dk> <394F9765.21D28D31@skynet.be> <8ionb2$a77g$1@xinwen.cs.au.dk> NNTP-Posting-Host: ufleku.cs.au.dk Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: xinwen.cs.au.dk 961545839 339111 255.255.255.255 (21 Jun 2000 00:03:59 GMT) X-Complaints-To: news@cs.au.dk NNTP-Posting-Date: 21 Jun 2000 00:03:59 GMT X-Attribution: Ahe User-Agent: Gnus/5.0806 (Gnus v5.8.6) Emacs/20.6 Xref: news.cs.au.dk comp.lang.beta:12469 >>>>> "JLK" == Jorgen Lindskov Knudsen writes: JLK> Well, it's a little difficult to discuss in short messages on a JLK> newsgroup, but the argument goes something like: for JLK> well-defined systams/components, the exception handling is an JLK> intrinsic part of the system design (there are actually people JLK> who states, that taking the design offspring in the exceptional JLK> cases, leads to better designs). Since it is part of the JLK> design, we should use controlable constructs (i.e. constructs, JLK> that are predictable from the source code), implying that static JLK> constructe are prefered. [aggreed: this is a short answer, but JLK> I hope it will do :-)] Often I find the static exceptions less convenient than static exceptions and am not convinced by this argument. A programmer can restrict himself to use dynamic exceptions in a way that doesn't obscure program flow. But let us not argue which type of exception is better; it is, as Jørgen already has pointed out, a religious matter. I come to wonder about constructs that are predictable from the source code, going back to my favorite example, getInt. Consider this program fragment: .... getInt -> i; .... Here, both with static or dynamic exceptions, it isn't immediate from the source code that a runtime error (uncaught exception) can happen. In Java I think this has been solved by requiring that all uncaught exceptions are listed in the function prototype. Are there any plans for addressing this in BETA?