Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37805

Re: Two exceptions

Show all headers | View raw

Responding to Eric Sosman:
> On 12/9/2017 11:15 AM, Stefan Ram wrote:
>>    The type of a result of a parse is
>> 
>> class ParseResult { ...
>> 
>>    which can have subclasses
>> 
>> class ProperParseResult extends ParseResult { ...
>> class ErrorParseResult extends ParseResult { ...
>> 
>>    which in turn can have several subclasses each of which
>>    might implement several interfaces.
>> 
>>    A parseResult might contain other parseResults (AST).
> 
>      This would work, yes, but I think it would lead to clumsy
> code at the call site, something like
> 
> 	ParseResult result = parse();
> 	if (result instanceof ProperParseResult) {
> 	   ProperParseResult ppr = (ProperParseResult) result;
> 	   ...
> 	} else if (result instanceof ErrorParseResult) {
> 	    ErrorParseResult epr = (ErrorParseResult) result;
> 	    ...
> 	} else {
> 	    throw new IllegalStateException("bad result", result);
> 	}

Not necessarily, or rather, not at all. Ignoring the AST suggestion...

ParseResult could declare a #matched() method, equivalent to the
#matched field in your single-class example. Handling would be identical
to your suggestion, but the types would be clearer, IMHO. Members that
are "only relevant if" another member carries a certain value feels like
a code smell to me, too.

There could also be a ParseResult#resultValue() method that throws in
the ErrorParseResult case. This would give the top level caller the same
experience as in the exception-signaling approach, but based on a
cleaner implementation.

Furthermore there could be a ParseResult#fold[T]() method that takes two
lambdas, Object -> T and Throwable -> T, and invokes the corresponding
lambda for the success resp. error case.

Finally, the instanceof cascade could be replaced with a proper Visitor
implementation over ParseResult. Stefan mentioned the Visitor pattern,
but constrained it to the tree traversal context. It is primarily about
double dispatch, though, and would apply nicely to the ParseResult
hierarchy, where there's no tree in sight.

Actually, all the approaches listed above could be supported in
parallel, leaving the result resolution style to the discretion of the
caller - which is what the author(s) of parsecj[1] opted for (excluding
the Visitor option).

The next step from this approach might be the introduction of
combinators that merge multiple results into one.

Best regards,
Patrick

[1] https://github.com/jon-hanson/parsecj#types

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

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