Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #37773
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Two exceptions |
| Date | 2017-12-09 07:39 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <p0glhg$abn$1@dont-email.me> (permalink) |
| References | <p0f54o$n5f$1@gioia.aioe.org> <p0f6p8$256$1@dont-email.me> <p0f8pt$s13$1@gioia.aioe.org> |
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 ...
}
... 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.
--
esosman@comcast-dot-net.invalid
Eleven hundred thirty-eight days to go.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Two exceptions Victor Porton <porton@narod.ru> - 2017-12-09 00:53 +0200
Re: Two exceptions Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-12-08 18:21 -0500
Re: Two exceptions Victor Porton <porton@narod.ru> - 2017-12-09 01:55 +0200
Re: Two exceptions Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-12-09 07:39 -0500
Re: Two exceptions Victor Porton <porton@narod.ru> - 2017-12-10 02:39 +0200
Re: Two exceptions Victor Porton <porton@narod.ru> - 2017-12-10 02:46 +0200
Re: Two exceptions Kiwi User <martin@mydomain.invalid> - 2017-12-10 00:52 +0000
Re: Two exceptions Patrick Roemer <sangamon@netcologne.de> - 2017-12-09 13:47 +0100
Re: Two exceptions Arne Vajhøj <arne@vajhoej.dk> - 2017-12-08 18:49 -0500
Re: Two exceptions v_borchert@despammed.com (Volker Borchert) - 2017-12-09 07:53 +0000
Re: Two exceptions Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-12-09 14:55 -0500
Re: Two exceptions Patrick Roemer <sangamon@netcologne.de> - 2017-12-11 15:09 +0100
csiph-web