Path: csiph.com!news.bbs.geek.nz!.POSTED.agency.bbs.geek.nz!not-for-mail From: Victor Porton (Victor Porton) Newsgroups: comp.lang.java.programmer Subject: Re: Two exceptions Date: Sun, 10 Dec 2017 02:46:10 +1200 Organization: fsxNet Usenet Gateway | bbs.geek.nz/#fsxNet Message-ID: <378316829@f38.n261.z1.binkp.net> References: <3640044093@f38.n261.z1.binkp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: news.bbs.geek.nz; posting-host="M6YmRdZYyc42DJk0lNlt/X4dpP4dzvceBNabSmESN3E"; logging-data="1216"; mail-complaints-to="abuse@news.bbs.geek.nz" User-Agent: VSoup v1.2.9.47Beta [95/NT] X-Comment-To: Victor Porton X-MailConverter: SoupGate-Win32 v1.05 Xref: csiph.com comp.lang.java.programmer:37797 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