RFC: Netx - implement -Xclearcache command line option
Dr Andrew John Hughes
ahughes at redhat.com
Thu Oct 7 14:33:12 PDT 2010
On 17:39 Wed 06 Oct , Omair Majid wrote:
snip...
> >
> > Does it have to be called R and not 'translate' or something more readable?
> >
>
> I am sure we can change it to something more sensible. I was just
> sticking with what the rest of Netx uses (there is already a R function
> in the same class). Still, I would like to handle that in a separate
> patch if it is ok.
>
> BTW, I am sure you know that a lot of programs use _ as the translate
> function. Is _ a valid java identifier? ;)
>
Yeah, you can use '_', I just checked. I presume you could also use $ but that's usually
reserved for autogenerated code.
I agree this is something to fix in a different patch. I'm not too familiar
with the NetX code so these things come as a surprise to me :-)
> >>> Should we really be catching IOExceptions rather than allowing them to propogate?
> >>>
> >>
> >> Catching IOExceptions is just ignoring the errors. So the question is do
> >> we want to ignore the errors and continue on or should we stop if we hit
> >> any errors. Since the lock file is meant to stop a race condition
> >> (between deleting jars and using them) which is not likely to happen, I
> >> think an error in lock file creation should be ignored. If for some
> >> reason a lock file can not be created, Netx should not abort running the
> >> application. If you dont think this makes sense, please let me know and
> >> I will change it.
> >>
> >
> > That sounds sensible. I'm just always wary of catch blocks. I've seen them
> > used all too often to mask exceptions instead of handling them (including in
> > example code used by lecturers!)
> >
>
> Heh. That's true. I think checked exceptions even (sort of) encourage
> this. I am afraid of swallowing exceptions too (or worse, handling them
> at the wrong level), but in this particular instance it makes sense to
> do just that.
>
Yeah I agree on that score.
> Thanks for looking over the changes.
>
No problem, please commit to the usual quartet of code trees.
> Cheers,
> Omair
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the distro-pkg-dev
mailing list