On Tue, 8 Jun 2004, Norman Gray wrote:
> On Mon, 7 Jun 2004, Peter W. Draper wrote:
>
> > Mark & Norman (mostly),
> >
> > [...]
> > Playing around with all this has left me with the impression that the URL
> > class is a mess, as it's possible to construct illegal states quite
> > easily, and it offers little to help you out of the mess. URI seems a much
> > better formulated class, so should probably be the one to use when there's
> > a choice.
>
> I just looked at this now, and I hadn't realised how shoddy the URL
> class is. Two things:
>
> I discovered that the File class has a toURI method, which presumably
> handles whatever escaping of the `prefix' (ie, drive-letter) is
> necessary. Therefore it looks as if any file URIs or URLs that are
> being constructed should go via that route.
Hi Norman,
that's what I concluded and many of the changes I introduced do just that
(File.toURI().toURL()).
> I wondered about simply removing the urlToUri method, but realised that
> it's used in such contexts as getImage().getURL(): getImage must return
> a URL rather than a URI, since it really has to be dereferencable -- it
> doesn't make sense to have a non-dereferenceable URI being returned
> here. Instead, I suggest rewriting urlToUri by decomposing the URL and
> reconstructing it with a multi-argument URI constructor, which does
> _all_ the necessary escaping. Secondly, I'll have it throw a
> HdxException rather than an AssertionError.
>
> Is there a case for a util-specific subclass of HdxException here? I
> don't think so, but could be persuaded.
That sounds more robust, but it probably isn't a good idea to introduce a
HDX dependency into UTIL (either by throwing a HdxException or by
subclassing this), better to throw something more generic I'd say.
Peter.
|