I'll give you a good reason... file access inevitably risks
IOExceptions, and exceptions don't propogate well from a static block.
That is to say, when the ClassLoader invokes the static block, it is
not invoked from within your code. The exception gets thrown and propogates
through the *ClassLoader* stack rather than your application code, resulting
in an application that simply won't start for mysterious reasons, forcing a
long and drawn out investigation.
The only reason I use static blocks any more is to initialize
constants that require more than 1 line to initialize correctly (such as
NumberFormats, where you may have additional methods to invoke once they are
corrected) or are order-dependent, so that if a field gets renamed and/or
the members are resorted the code doesn't blow up.
Even these examples are pretty scarce and serve very special purposes.
Best Practice: Don't do anything in a static block that can throw an
exception without good reason.
If you have something you'd like to initialize in a static way,
create a static synchronized accessor and allow the accessor to throw
exceptions as needed. i.e.
a singleton-like implementation:
private static Config configInstance = null;
public static final synchronized getConfig()
{
if(configInstance==null)
{
// create instance and read config;
// this can throw any RuntimeExceptions
// and still be compatible with the signature
}
return configInstance;
}
David Hibbs, ACS
Staff Programmer / Analyst
American National Insurance Company
> Id be wary about using static blocks for anything involving
> file access. I
> cant give you a good reason for that, but it just seems like
> a bad idea to
> me.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
