Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44D35DC1.1000803@apache.org>
Date: Fri, 04 Aug 2006 15:46:25 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Do not raise exception when you can prevent it
 (was	Re:	svn	commit:
 r428677)
References: <20060804094424.BC1BB1A981A@eris.apache.org>
	 <1154689722.8136.18.camel@localhost.localdomain>
	 <44D32E06.3050404@apache.org>
	 <1154692591.8136.35.camel@localhost.localdomain>
	 <44D340D0.1030108@apache.org>
 <1154700699.8136.70.camel@localhost.localdomain>
In-Reply-To: <1154700699.8136.70.camel@localhost.localdomain>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Thorsten Scherler wrote:
> El vie, 04-08-2006 a las 13:42 +0100, Ross Gardler escribi=C3=B3:

=2E..

> Please review the commit carefully since what you say is not true. I
> forgot to throw the exception on the end (what I fixed now) but *All*
> other messages "which files loaded OK" are still there!

Yeah, you are right.

>>>No, this is a general issue, that we all need to keep watching. If not=
,
>>>we  will start catching NPE for debugging. That is just bad programmin=
g.
>>
>>That's a hell of leap in usage patterns. There is no correlation betwee=
n=20
>>trapping an IOException and trapping a runtime exception.
>>
>>In my view it is correct to trap *all* checked exceptions (i.e. not=20
>>runtime) and handle them appropriately. If the code can't deal with the=
=20
>>situation then it throws a runtime exception which is bubbled up to the=
=20
>>user.
>=20
>=20
> ...but why provoking instead of prevent them?

Sorry I don't understand provoking what? If you mean your proposal to=20
use source.exist() instead of try {...} catch (FileNotFound e) {...} I=20
have never objected to that specific example.

If you mean something else then I don't get it.

>>However, you go on to support your argument with the point that it is=20
>>less efficient to raise the exception than it is to prevent the=20
>>exception happening. This is not always the case.
>=20
>=20
> Actually I just picked up your argument of efficiency. Neither of us ca=
n
> proof which is more efficient.=20

Not in general terms, no. That is my point.

>>Imagine a situation when the exception is rarely thrown, e.g. the file =

>>exists in 99.9% of projects. In this instance it is more efficient to=20
>>assume the file exists and to handle the odd occasion it doesn't than i=
t=20
>>is to test for existence every time.
>=20
>=20
> Disagree, see the link that Tim provided.

I read the article, and like most JavaWorld articles I found it to be a=20
gross simplification of a complex matter.

>>Hence I am -1 on prescribing only one way of handling this situation.=20
>>I'm OK with having guidelines describing which approach to take in=20
>>different situations.
>=20
>=20
> hmm
>=20
> Let us try to find consensus on this ASAP because I see this thread
> starting again being an end(sense)less discussion.

Well, I've agreed with the principle of what you say. I also agree that=20
in most cases what you say is applicable (including in the case of the=20
ForrestConf module that sparked this discussion)

I do not agree with the way you have implemented this proposal in the=20
ForrestConf code (see comments on commit messages)

I do not agree that we should have a coding standard that defines *one*=20
and only *one* way of doing this. Having one that describes what is the=20
common case is fine. Encouraging people to read an observe this is fine, =

but I am not happy with having it as a standard (meaning different=20
approaches cannot be used) since there *are* situations that other=20
approaches are appropriate.

For example, caching and reloading of the forrest.properties.xml file=20
has been proposed. I also want to make it that the config file can be=20
pulled from a remote resource. In this instance checking for existence=20
is more expensive (network roundtrip) than instantiating an eception.

Just to be clear, my -1 is to the idea of having only one way of doing=20
this, it is not to the idea of having a guidance document.

Ross