Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 11605 invoked from network); 18 Apr 2006 12:50:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 Apr 2006 12:50:42 -0000 Received: (qmail 31757 invoked by uid 500); 18 Apr 2006 12:50:37 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 31435 invoked by uid 500); 18 Apr 2006 12:50:35 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 31424 invoked by uid 99); 18 Apr 2006 12:50:35 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Apr 2006 05:50:35 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [134.134.136.20] (HELO orsmga101-1.jf.intel.com) (134.134.136.20) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Apr 2006 05:50:33 -0700 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 18 Apr 2006 05:50:13 -0700 Received: from fmsmsx331.fm.intel.com (HELO fmsmsx331.amr.corp.intel.com) ([132.233.42.156]) by orsmga001.jf.intel.com with ESMTP; 18 Apr 2006 05:50:13 -0700 X-IronPort-AV: i="4.04,130,1144047600"; d="scan'208"; a="24436018:sNHT18027289" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 05:49:52 -0700 Received: from mssmsx402.ccr.corp.intel.com ([10.125.2.12]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 05:49:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: should strings in exceptions match the reference implementation? Date: Tue, 18 Apr 2006 16:49:46 +0400 Message-ID: <6694B22B6436BC43B429958787E4549801CCD5F1@mssmsx402nb> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: should strings in exceptions match the reference implementation? Thread-Index: AcZi33vpoNG7mFPaRlSH52HE/lYyqAAA1pzA From: "Semukhina, Elena V" To: X-OriginalArrivalTime: 18 Apr 2006 12:49:52.0295 (UTC) FILETIME=[95DD5B70:01C662E6] X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Just one more example. Should users feel comfortable when getting the RI's message "java.lang.ArithmeticException: Division impossible"? Isn't it better for a class library to provide=20 "java.lang.ArithmeticException: integer part of the quotient needs more than 11 digits" to help our users find the cause of an exception? Regards, Elena Semukhina Intel Middleware Products Division >-----Original Message----- >From: Geir Magnusson Jr [mailto:geir@pobox.com] >Sent: Tuesday, April 18, 2006 6:56 PM >To: harmony-dev@incubator.apache.org >Subject: Re: should strings in exceptions match the reference >implementation? > >Yes - great example. The point is for mechanical means, but familiarity >for users - we don't want them to be "uncomfortable" when using the >Harmony class library - we want it to feel the same as when they use it >from Sun... > >geir > > >Mark Hindess wrote: >> I thought my first message in this thread made this clear but obviously >not. >> >> I'm not suggesting that code would care if the exception messages are >> identical. I was suggesting that it is probably now quite common for >> users to type error messages straight in to google. Therefore having >> messages match those of existing implementations would help our users >> find the cause of an exception. >> >> Regards, >> Mark. >> >> On 4/18/06, Chris Gray wrote: >>> On Tuesday 18 April 2006 09:37, Mark Hindess wrote: >>>> Are you saying that Classpath does match strings in exceptions? >>> No. Ah, I see: the "do" in Geir's question stood for "what is >Classpath's >>> policy wrt to exception messages matching those of the RI?". Then I >don't >>> speak authoritatively, but I've never noticed Classpath going out of its >way >>> to be compatible at this level. But then I would never write code which >>> depended on the precise contents of an exception message ... >>> >>> Sorry for the confusion, >>> >>> Chris >>> >>> -- >>> Chris Gray /k/ Embedded Java Solutions BE0503765045 >>> Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/ >>> chris.gray@kiffer.be +32 3 216 0369 >>> >>> >>> --------------------------------------------------------------------- >>> Terms of use : http://incubator.apache.org/harmony/mailing.html >>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org >>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org >>> >>> >> >> >> -- >> Mark Hindess >> IBM Java Technology Centre, UK. >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org >> >> > >--------------------------------------------------------------------- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org >For additional commands, e-mail: harmony-dev-help@incubator.apache.org --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org