On Tue, 8 Jun 2004, Norman Gray wrote:
> Peter and Mark,
>
> On 2004 Jun 8 , at 16.58, Norman Gray wrote:
>
> > Good point. I'll translate the URISyntaxException into
> > MalformedURLException (which is what the problem really is) and throw
> > that.
>
> Done. As part of this I added testcases for URLUtils.
>
> I included testcases for URLUtils.makeURL (Mark, that's yours, yes?),
> and included a couple of URLs which I thought it would/should object
> to. I was a bit surprised to find that it didn't object, as a result
> of its heuristic for working out whether it's making a `file:' URL or
> not. Mark, could you look at these and see if you think they should
> succeed?
The makeURL method is behaving as I intended and as documented, but
what I didn't document is why I've written a method like this, so
your surprise is reasonable.
The makeURL methods are convenience methods intended for when
you obtain a string (typically typed in by a user) which represents
the location of a resource. To make life easy for the user
you want them to be able to submit either a filename or a URL
(i.e. not force them to prepend 'file:' to the start of a filename).
So a typical usage is:
InputStream getStream( String location ) throws IOException {
URL url = URLUtils.makeURL( loc );
return url.openStream();
}
If the location string is "weirdproto:not.here.mate" then this just
throws FileNotFoundException with message
"weirdproto:not.here.mate (No such file or directory)".
Unless of course a file called "weirdproto:not.here.mate" is present
in the current directory. And you don't have to muck about with
MalformedURLExceptions.
The point is that it deliberately doesn't attempt to throw out
certain strings that it doesn't like the look of, on the grounds
that you'll get a caught exception (probably an IOException) from
them soon enough anyway.
Mark
--
Mark Taylor Starlink Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|