Warning during class initialization

[Ian Pilcher]

I am writing a class which (ideally) will be part of a fairly general
library. I want to allow a "magic constant" to be overridden by a
system property.

This means that I need to do some error checking on the value of the
property (if present) and fallback to the default value if necessary.
I would very much like to issue/log a warning message in this situation.

Am I correct that J2SE does not provide any general purpose logging
mechanism? If so, what's the "best practice" for this situation?

Thanks!

 

[Oliver Wong]

I am writing a class which (ideally) will be part of a fairly general
library. I want to allow a "magic constant" to be overridden by a
system property.

This means that I need to do some error checking on the value of the
property (if present) and fallback to the default value if necessary.
I would very much like to issue/log a warning message in this situation.

Am I correct that J2SE does not provide any general purpose logging
mechanism? If so, what's the "best practice" for this situation?

Thanks!

J2SE has a packaged called java.util.logging which may serve your needs.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/package-summary.html

- Oliver

 

[Ian Pilcher]

J2SE has a packaged called java.util.logging which may serve your needs.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/package-summary.html

Thanks for the pointer.

Unfortunately, there doesn't seem to be a way for a library class to use
a "default logger" that could be set by the application.

Or am I missing something?

 

[Thomas Weidenfeller]

Unfortunately, there doesn't seem to be a way for a library class to use
a "default logger" that could be set by the application.

Or am I missing something?

http://java.sun.com/j2se/1.5.0/docs/guide/logging/overview.html

Section 1.8ff

/Thomas

 

[Chris Uppal]

Am I correct that J2SE does not provide any general purpose logging
mechanism? If so, what's the "best practice" for this situation?

Redesign. You have just three options.

Swallow the error silently.

Throw an exception that will kill the app.

Change your API so that the application is in control of when/how the setting
is, er, set. In that way you will have a natural route to report errors --
specifically, your class will have someone to report errors /to/. (That
reporting might be to throw an exception, to log to a well-known object
(singleton or similar), to report to an application-specified error handler,
or...).

Basically, the problem is that class initialisation is too early to be
performing operations which don't always work perfectly.

-- chris