Skip to main content

ClassLoaders use Exception for flow-control, don't they?

5 replies [Last post]
linuxhippy
Offline
Joined: 2004-01-07
Points: 0

I am currently implementing my own ClassLoader which acts in a very low level in the class-loader hirachy.

Most time (99.9%) of the time the ClassLoader will simply not find the approriate class and therefor throw an ClassNotFoundException, as it should.

It works, but isn't there a better way for telling the class-loader hirarchy that my class loader was not able to find the class? This way I am throwing thousands of exception where a "return null" could do the same.

lg Clemens

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tackline
Offline
Joined: 2003-06-19
Points: 0

> Well if I am in the class-loader hirarchy I have to
> throw exceptions, theres no way arround that.

You have to throw an exception, but not necessarily construct one every time...

I'm now skeptical as to whether exceptions really are a problem for non-bootstrap class loading. I'd be interested to profiling of class loads.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

> I'm now skeptical as to whether exceptions really are
> a problem for non-bootstrap class loading. I'd be
> interested to profiling of class loads.

Well in our case we throw ~5000 CNFE's (of course we share, but this only saves construction time which is low anyhow), I'm not sure which effects this has on execution time.

I wonder more about the fact that a golden-rule of java development is to not to use Exceptions for control-flow.
Escepcially in this case where a simple "null" would do a perfect job.

However now its too late, this stuff has been designed somewhere in 1996/97 ;)

lg Clemens

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

What are your concerns with throwing CNFE?

If it is a case where failure rate is expected to be high, try implementing a say doesClassExist(String path) in your ClassLoader to overcome the performance issues w.r.t Exceptions that I guess you are trying to avoid here.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

> What are your concerns with throwing CNFE?
A complete stack-trace has to be generated (at least when running on client jvm) which is slow.
Furthermore thrown exceptions for control flow has been be-deviled by java devs thousands of times.

> If it is a case where failure rate is expected to be
> high, try implementing a say doesClassExist(String
> path) in your ClassLoader to overcome the performance
> issues w.r.t Exceptions that I guess you are trying
> to avoid here.
Well if I am in the class-loader hirarchy I have to throw exceptions, theres no way arround that.
Also if classes are loaded automatically (by the jvm for resolving class-references) this won't help at all :-/

I wonder why the jvm engineers specified that throwing a CNFE instead of simply returning null?

lg Clemens

lg Clemens

ronaldyang
Offline
Joined: 2003-06-19
Points: 0

I'd be interested in hearing benchmark figures w.r.t. the following: did you know there's a jvm option -XX:-StackTraceInThrowable

I guess the rationale is that ultimately there are cases where the user needs to see a ClassNotFoundException. Maybe from inside a ClassLoader it doesn't make sense to discriminate when you should return null vs throw an Exception.