Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8451

Re: Avoid creating a stacktrace prior to JDK 1.7

Show key headers only | View raw

Lew schrieb:
> in the first place.
>
> /Effective Java/, Joshua Bloch, "Item 57: Use exceptions only for exceptional conditions".

The JDK itself violates this rule. For example
each time a Thread is created the following
check is run:

     /**
      * Performs reflective checks on given subclass to verify
      * that it doesn't override security-sensitive non-final
      * methods. Returns true if the subclass overrides any of
      * the methods, false otherwise.
      */
     private static boolean auditSubclass(final Class subcl) {
         Boolean result = AccessController.doPrivileged(
             new PrivilegedAction<Boolean>() {
                 public Boolean run() {
                     for (Class cl = subcl;
                          cl != Thread.class;
                          cl = cl.getSuperclass())
                     {
                         try {
 
cl.getDeclaredMethod("getContextClassLoader", new Class[0]);
                             return Boolean.TRUE;
                         } catch (NoSuchMethodException ex) {
                         }
                         try {
                             Class[] params = {ClassLoader.class};
 
cl.getDeclaredMethod("setContextClassLoader", params);
                             return Boolean.TRUE;
                         } catch (NoSuchMethodException ex) {
                         }
                     }
                     return Boolean.FALSE;
                 }
             }
         );
         return result.booleanValue();
     }

In the above the sunshine flow is that we get a boolean
value false, which means that two NoSuchMethodExceptions
are thrown. It seems that in connection with the reflection
API using the exceptions for business logic has become
the prefered idiom contrary to the advice.

But this is probably due to a lack of a better reflection
API. Or we can even analysis it deeper. Since the reflection
API methods can return so much information AND since java
does not have multi valued returns, the exceptions have
been abused for returning additional information.

In the Go Programming language one would do something:

     getDeclaredMethod(String,Class[]) (Method,Error)

Shit happens!

P.S.: Actually the situation is worse in JDK 1.7, the
audit is done but then cached during the call of
isCCLOverridden(). This is good. But each call of
isCCLOverridden() does also poll the cache for
removal of inaccessible keys! Hm, not sure what
I should think about that.

Bye

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-09-30 15:57 +0200
  Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 13:27 +0300
    Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 13:22 +0200
      Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 09:10 -0700
        Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 20:31 +0300
        Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 20:02 +0200
          Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 12:21 -0700
            Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 22:04 +0200
              Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-01 16:24 -0400
                Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 23:14 +0200
                Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-01 17:28 -0400
                Re: Avoid creating a stacktrace prior to JDK 1.7 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-01 23:45 +0000
                Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-02 00:58 +0300
                Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-02 02:04 +0200
                Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 20:06 -0700
                Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-02 13:14 +0300
                Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-02 08:37 -0700
                Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-02 20:26 +0200
                Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-02 17:51 -0400
                Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-03 01:32 +0200
    Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 20:19 +0300
      Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 20:04 +0200
        Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 21:15 +0300

csiph-web