From dev-return-123857-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Tue Feb 01 23:28:14 2011 Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 96695 invoked from network); 1 Feb 2011 23:28:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Feb 2011 23:28:13 -0000 Received: (qmail 27056 invoked by uid 500); 1 Feb 2011 23:28:13 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 26938 invoked by uid 500); 1 Feb 2011 23:28:12 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 26930 invoked by uid 99); 1 Feb 2011 23:28:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Feb 2011 23:28:12 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of GGregory@seagullsoftware.com designates 216.82.250.99 as permitted sender) Received: from [216.82.250.99] (HELO mail126.messagelabs.com) (216.82.250.99) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Feb 2011 23:28:03 +0000 X-VirusChecked: Checked X-Env-Sender: GGregory@seagullsoftware.com X-Msg-Ref: server-3.tower-126.messagelabs.com!1296602858!90848574!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [137.134.240.188] Received: (qmail 19326 invoked from network); 1 Feb 2011 23:27:39 -0000 Received: from unknown (HELO postal.rocketsoftware.com) (137.134.240.188) by server-3.tower-126.messagelabs.com with AES128-SHA encrypted SMTP; 1 Feb 2011 23:27:39 -0000 Received: from NWT-S-MBX2.rocketsoftware.com ([fe80::5161:f503:4728:78ad]) by nwt-s-cas1.rocketsoftware.com ([::1]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 18:27:27 -0500 From: Gary Gregory To: Commons Developers List Subject: RE: [all][math] Help wanted with exceptions API design Thread-Topic: [all][math] Help wanted with exceptions API design Thread-Index: AQHLwhdAjeJW+wq51EC4OMQt8pz485Psz/mQgADLsYD//66MQA== Date: Tue, 1 Feb 2011 23:27:26 +0000 Message-ID: <02AA127CD8DCDE48BC7D2DFB6C87083A07E54837@nwt-s-mbx2.rocketsoftware.com> References: <1306776012.1389141296568027913.JavaMail.root@spooler6-g27.priv.proxad.net> <1969100260.1391011296568344161.JavaMail.root@spooler6-g27.priv.proxad.net> <02AA127CD8DCDE48BC7D2DFB6C87083A07E54104@nwt-s-mbx2.rocketsoftware.com> <20110201231611.GP22170@dusk.harfang.homelinux.org> In-Reply-To: <20110201231611.GP22170@dusk.harfang.homelinux.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org > -----Original Message----- > From: Gilles Sadowski [mailto:gilles@harfang.homelinux.org] > Sent: Tuesday, February 01, 2011 18:16 > To: dev@commons.apache.org > Subject: Re: [all][math] Help wanted with exceptions API design >=20 > > > > > The currently defined exceptions in [math] can be found in the > > > > > top-level package and .exceptions. =A0Those in the top-level have= at > > > > > this point been deprecated. > > > > Don't package your exceptions in a package called ".exceptions". That i= s > very odd. >=20 > Why? >=20 > > The exception should be defined where they are used. >=20 > What do you do for exceptions that are used in several classes and severa= l > packages? Here is a probably too simple example:=20 com.example defines IOException com.example.input uses IOException com.example.output uses IOException >=20 > > As I and others have suggested: reuse existing stock exceptions. Only > create exceptions classes if you must. >=20 > Depending on the requirements, the exceptions we created may be more > convenient. >=20 > > If you consider creating an exception, especially in a hierarchy, think= : > why would I want to CATCH this exception as opposed to a superclass? >=20 > I don't agree because I don't consider from that stand-point. IMHO, the > exception is useful if it conveys a problem as specifically as possible. > The caller is free to catch, or not, whatever he likes. >=20 >=20 > Best, > Gilles >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org