tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Correct behavior while checking the thread binding in DirContextURLStreamHandler ?
Date Thu, 02 Feb 2012 15:08:03 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pid,

> On 01/02/2012 11:50, Ivan wrote:
>> 2012/2/1 Christopher Schultz <chris@christopherschultz.net>
>> 
>> Of course, you still need to check for null after the loop, so
>> it's not like the change really affects anything other than minor
>> readability.
> 
> No sure whether I understood you clearly,  if a context is binding
> on the current thread, and current context classloader has parent
> classloader, current get method will throw an
> IllegalStateException. So my question is that, in this scenario,
> should the context binded on the thread be ignored ? I did not find
> too many comments on the svn log, while I guess that the logic may
> be : a. Check whether there is a context binding on the current
> context classloader, if does, return it. b. Check whether there is
> a context binding on the current thread, if does, return it. c.
> Check whether there is a context binding on the classloader tree of
> the current context classloader, if does return it. d. Throw an
> IllegalStateException.

I still can't figure out if you think there's an actual bug here.

Is the problem that you object to illogical code? Is there a branch
that does not need to exist because you can prove that a certain
situation will never arise?

I find this kind of thing sometimes when using FindBugs: fb will tell
me that a certain local variable being checked for null somewhere
results in dead-code in the body of the if, like this:

if(null != conn) { conn.close(); }

fb says that "conn" can never be non-null here, so the code is dead. I
always tell fb to ignore that because I don't want to modify the code
sometime in the future such that "conn" *might* be null and forget to
add the null-check (or conn.close) back into the code.

Defensive programming sometimes results in illogical code.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8qptMACgkQ9CaO5/Lv0PCV+ACeIx3y69FvjIbaasS2seLtDqm4
lEUAnipaSpnrn1Figs0TQ9ucS+FN3+5I
=nWlV
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message