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

Groups > comp.lang.java.programmer > #37824 > unrolled thread

Re: Two exceptions

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Two exceptions Victor Porton <porton@narod.ru> (Victor Porton) - 2017-12-12 11:14 +1200

#37824 — Re: Two exceptions

Patrick Roemer wrote:
> 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

You can see my actual code which I have written (without exceptions except of
FatalParseError) at

https://github.com/vporton/xml-boiler/tree/master/core/src/main/java/org/boiler
/rdf_recursive_descent

--
Victor Porton - http://portonvictor.org

[toc] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web