Re: [Gnu-arch-users] Nit

[Dustin Sallings]

On Tuesday, Oct 21, 2003, at 14:49 US/Pacific, Tom Lord wrote:

> It must be handled _somewhere_up_the_call_graph_.  It must be in the
> throws list of my method.  But Java does _not_ require that it be
> handled at the call-site.  It's that distinction that is at issue.

	I understand what you're saying about throws-per-call, and it sounds 
like an interesting idea, but as you say, it isn't much different from 
return values.  I believe this reduces the value.

        To be concrete:

        public List getLinesOfFile(String f) throws IOException {
                String realFile=translatePath(f);
                InputStream is=openTheStream(realFile);
                List rv=getLinesOfStream(is);
                is.close();
                return(rv);
        }

	In the above example, each of openTheStream, getLinesOfStream, and 
close() may raise an IOException.  translatePath looks up its mapping 
in an internal Map, and if the value is not found, returns the passed 
value.  (For clarity, I've left out the finally block to deal with 
is.close().  If you're uncomfortable with that, assume the frequency of 
this method call is small enough that the stream finalization is 
sufficient).

	However, we've found that our translation map is too large and now has 
to use a cdb or something to perform the translation.  Now, 
translatePath may also throw an IOException which was previously not an 
expected failures state.

	The question, then, is whether translatePath()'s exception causes the 
program to be incorrect now.  I do not believe it does.  Although a new 
reason has been introduced, it is still an IO problem in that there 
isn't much of a difference between an inability to open a file and an 
inability to locate the path to a file to the higher level.

	If there is, a new type of exception should be introduced.  If not, a 
subclass of IOException (PathMappingException?) could still be 
introduced without changing the signature of the method.

	This is the contract of this method.  It will return a List, or an 
excuse via an IOException.  If the caller needs more information than 
what's provided by the published API, it's an abstraction leak.

--
Dustin Sallings