Note that the current implementation already does some of this catch and set to null business WRT SecurityExpections. The additional layer needed to create a File object would be wrapped in a method that checks for null. What I like about the static final idea is that it does convey the idea that the value will not change, unlike a method call. OTOH, calling System.getProperty does not say anything about the value not changing, so I guess I'd be fine with a method or a field.
Gary > -----Original Message----- > From: __matthewHawthorne [mailto:[EMAIL PROTECTED] > Sent: Monday, December 29, 2003 16:56 > To: Jakarta Commons Developers List > Subject: Re: [lang] SystemUtils.JAVA_IO_TMPDIR > > Stephen Colebourne wrote: > > It would definitely need to be protected in construction to avoid > exceptions > > and set the value to null if it fails. > > I think that static methods may be a cleaner approach, instead of a > static block which much catch IOExceptions when constructing the static > File objects. > > This would elminate the convenience of having static fields, but the > possibility of receiving NullPointerExceptions instead of IOExceptions > after an error doesn't seem favorable to me. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
