cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <...@dds.nl>
Subject Re: [RT] Checked exceptions considered harmful
Date Thu, 15 Apr 2004 07:50:47 GMT


Bertrand Delacretaz wrote:
> Le 14 avr. 04, à 20:00, Leon Widdershoven a écrit :
> 
>> ...I don't think throws Exception in all declarations is a plus; a 
>> function which operates on files could have an IOException, a function 
>> which operates on numbers a NumberException
>> or something akin; in essence, the root of the expected Exception 
>> hierarchy (for interfaces and abstratc classes)....
> 
> 
> I like the idea, similar to what Berin suggests: using base exceptions 
> which tell us what the problem is about, without being too specific.
> 
> -Bertrand
> 

Similar but *not* the same. And it holds only for interfaces. I think the
actual classes should be a bit more specific (not just Exception - that 
doesn't tell anything).

But to give an example, I define a virtual DataSource (not a cocoon/avalon one):

interface DataSource {
// ...
	public String getData() throws IOException;
}

In does not matter why a datasource could not get the data. Whether
a file is not found, could not be read, a netwerk address is not available,
a database does not exist, an SQLException occurred - for this function
it only matters that no input could be obtained.

An implementation should then of course re-wrap the exception to an IO
exception. With an appropriate message (I think cocoon has good exception
messages btw).

I think it is important in such a case to be generic since it is extremely 
hard for software to automatically correct any problem in such a case.
You might want to access a backup data source, but for that you only need to
know that the operation has failed. Not exactly why (it should be in the
logs though). If you/the software knew a file does not exist, could it
automatically create one with the requested data? Normally not - if you
had the data you would not need to ask it.

That is why I think overly specific exceptions are not always the best
way - the exceptions you specify as a library developer should not just
image the exceptions thrown by used functions, but be of use to the calling
developer. And (s)he want's to know whether the action has failed.

Leon



Mime
View raw message