Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Victor Porton Newsgroups: comp.lang.java.programmer Subject: Re: Two exceptions Date: Sun, 10 Dec 2017 02:46:11 +0200 Organization: Aioe.org NNTP Server Lines: 59 Message-ID: References: NNTP-Posting-Host: Sz6TxwyziwPWhj5bu0SdBw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: abuse@aioe.org User-Agent: KNode/4.14.10 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:37786 Victor Porton wrote: > Eric Sosman wrote: > >> On 12/8/2017 6:55 PM, Victor Porton wrote: >>> Eric Sosman wrote: >>> >>>> On 12/8/2017 5:53 PM, Victor Porton wrote: >>>>> [... using exceptions to control a recursive descent parser ...] >>>> [... maybe exceptions aren't the best tool ...] >>>> Instead of announcing a "venial" mismatch by throwing an >>>> exception, >>>> consider returning a status value from each parse method. This might >>>> be a boolean ("It's an X1" / "It's not an X1") or a reference value >>>> ("It's an X1 and here it is" / "It's not an X1 and here's a null"), >>>> or something more structured ("Here's a status-and-result-and-info >>>> object; look at its fields to find out what happened"). [...] >>> >>> The main reason I chose to use exceptions for this, is to allow parse() >>> method to return the result of parsing (not a boolean value). For >>> example result of parsing an integer may return "long". >>> >>> Can you propose another alternative? It is to be easily programmable (if >>> I find handling exceptions too slow, I always can rewrite my program). >>> >>> Oh, I see, you proposed to return "null" instead of my ParseException. >>> It however also seems to me not a quite good solution, because returning >>> null may be a non-exceptionable situation (as for a missing optional >>> object in the parsed resource). >> >> If `null' is a legitimate result (so you can't use a `null' return >> to mean "Not matched"), use a status-and-result-and-info object like >> >> class ParseResult { >> final boolean matched; // true = success, false = failure >> final Object result; // only relevant if matched == true >> // ... other info as desired ... >> } > > I haven't considered this perhaps because Ada does not allow a class to be > a member of object (without wrapping it into something called > Indefinite_Wrapper or something similar). So in Ada this would be > inconvenient. Hm, well, I should have considered this. In Ada this can be made with a constructor function (just like as in Java) and an accessor hiding Indefinite_Wrapper as a details of implementation. Weird that I have not considered this. Well, maybe this is because I didn't wonder about performance very much and considered many exceptions OK. But thanks for the idea. I think, I will follow your advice and remove ParseException altogether leaving only FatalParseException. >> ... and return a ParseResult instance from each parse() method. The >> `result' field might be `null', but if `matched' is true the `null' is >> a "real" `null', not a failure indication. >> -- Victor Porton - http://portonvictor.org