Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 32820 invoked from network); 15 Apr 2002 17:29:40 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Apr 2002 17:29:40 -0000 Received: (qmail 28372 invoked by uid 97); 15 Apr 2002 17:29:44 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 28321 invoked by uid 97); 15 Apr 2002 17:29:44 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 28310 invoked from network); 15 Apr 2002 17:29:43 -0000 Message-ID: From: "Friedman, Eric" To: "'Lucene Developers List'" Subject: RE: about my proposed patch for bug 7782 Date: Mon, 15 Apr 2002 10:36:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Eugene, The problem with folding TokenMgrException into ParseException is that it's inconsistent with the parser generation framework provided by JavaCC. Simply put, a lexer error is not a parser error. Indeed, a smart parser may be able to gracefully recover from lexer errors. Yes, you can hack the generated classes, but first I'd like to believe that there's a good design reason for doing so. To my mind, the absence of an "is a" relationship between these two classes make such a move an abuse of inheritance. my 2 cents, Eric > -----Original Message----- > From: Eugene Gluzberg [mailto:drag0n2@yahoo.com] > Sent: Monday, April 15, 2002 7:56 AM > To: Lucene Developers List > Subject: Re: about my proposed patch for bug 7782 > > > Although I agree with you in theory, in practice we need to > be backwards > compatable as well is absolutelly correct. > > ParseException also does not nesseserally mean "syntax > error", it indicates > an error encountered during parsing. > > If you would like we can create 3 exception classes: > ParseException > TokenMgrException extends ParseException > SyntaxException extends ParseException > > but that would require significant changes thoughout the > code, which IMHO > should not be in this release. > > For this release we should just throw a ParseException. > > > > > To make a source code analogy: "return if break;" contains a set of > > valid tokens for the Java language, but the syntax is > invalid, making a > > ParseException the right kind of error to raise. > Conversely, "swAtch > > (c) { }" contains characters which cannot be recognized by > the lexer as > > a legal token, so a TokenMgrException is appropriate. > > > > I would strongly urge against blurring the distinction between these > > two classes of error, as they really are not the same thing. > > > > Eric > > > > > > -- > > To unsubscribe, e-mail: > > > For additional commands, e-mail: > > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: