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


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

Re: Two exceptions

Started byram@zedat.fu-berlin.de (Stefan Ram) (Stefan Ram) (Stefan Ram) (Stefan Ram)
First post2017-12-09 16:15 +1200
Last post2017-12-09 16:15 +1200
Articles 1 — 1 participant

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


Contents

  Re: Two exceptions ram@zedat.fu-berlin.de (Stefan Ram) (Stefan Ram) (Stefan Ram) (Stefan Ram) - 2017-12-09 16:15 +1200

#37795 — Re: Two exceptions

Fromram@zedat.fu-berlin.de (Stefan Ram) (Stefan Ram) (Stefan Ram) (Stefan Ram)
Date2017-12-09 16:15 +1200
SubjectRe: Two exceptions
Message-ID<4219645032@f38.n261.z1.binkp.net>
Victor Porton <porton@narod.ru> writes:
>So I have two alternatives:
>1. Derive ParseException from FatalParseException what seems to do the right
>thing but seems illogical.

  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).

  But without knowing more details of the problem, it is
  difficult to suggest further details.

>An object X may be either X1 or X2 or X3 class.

  When X is not X1, of course, this is neither an error
  nor a reason to throw.

  (Check whether you might use the anti-pattern "switch on
  (sub)type [i.e., X1, X2, X3]" whose use should be replaced
  by polymorphism.)

  Traversing given nested objects is not called "parsing"
  (which is working on a sequence of tokens), it is more like
  a tree travesal, which might suggest to check out the
  visitor pattern.

[toc] | [standalone]


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


csiph-web