Path: csiph.com!aioe.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk>
Newsgroups: comp.lang.java.programmer
Subject: Re: Two exceptions
Date: Fri, 8 Dec 2017 18:49:47 -0500
Organization: Aioe.org NNTP Server
Lines: 49
Message-ID: <p0f8eu$rir$1@gioia.aioe.org>
References: <p0f54o$n5f$1@gioia.aioe.org>
NNTP-Posting-Host: PBuS014lhzVyHjLbXmo/ZQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.java.programmer:37739

On 12/8/2017 5:53 PM, Victor Porton wrote:
> I am writing something like a recursive descent parser: That is, I inspect
> object and its parts. When a part of an object is wrong, my method parse()
> throws my exception ParseException. It is sometimes handled in parse() of a
> higher-level object.
> 
> Example:
> 
> An object X may be either X1 or X2 or X3 class.
> 
> I try to call parse() for an object of X1 class. If it parses, the higher
> level parse() (for X) return X1 casted to X. If it fails with exception
> ParseException, X2 is tried, and if that fails too X3 is tried.
> 
> Or for an object X I try calling parse() for subobjects Y and Z. If either
> throws ParseException, the parse exception is propagated for parse() of X.
> 
> In this way, I consider an object and its possible parts. This is sometimes
> called recursive descent.
> 
> But I want also FatalParseException meant to stop parsing of a file
> altogether if it happens in the object or its subobject.
> 
> Human logic suggests that FatalParseException is a kind of ParseException
> and so should be its subclass. But this way handling ParseException we would
> also handle FatalParseException what is wrong, because FatalParseException
> is meant to be handled only in the outer method, outside of all parse()
> methods.
> 
> So I have two alternatives:
> 
> 1. Derive ParseException from FatalParseException what seems to do the right
> thing but seems illogical.
> 
> 2. Not derive either of these two exceptions from each other.

First you need to decide if you really want to use exceptions for this.
It is usually frowned on to use exceptions to control flow. But OK
the Java API has some parse methods throwing checked exceptions.

If you want to proceed this route then I would go for:

3) Base-class ParseException with two sub-classes FatalParseException
    and NonFatalParseException.

I think that is the OO representation of your domain logic.

Arne