Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1481
  • Last Modified:

JApplets, unchecked exceptions, and beautified reporting

Hi there!  Hope someone can help me :-)

I looked at this:

http://www.javaspecialists.co.za/archive/Issue081.html

And it seems a really nice way of catching unchecked exceptions and sending an email report or something to the developers when an unchecked exception is caught...

But it only works in Applications...

My problem is I have a JApplet, and I want to do a similar thing;

1) User does something that causes an unchecked exception (index error, number format error, etc)
2) Users gets a dialog pop up, aking for a comment on what they were trying to do, and if they want to send the report to the developers
3) User clicks "send", and applet calls server, which fires off an email

Now, I can't use that method (from that link), as I do not create the applet...that is done by the browser...

I have tried (from the sublime to the ridiculous) ;-)

1)  Subclassing ThreadGroup to allow me to add the currentThread to my own ThreadGroup (like he has)
      -- fails, as I am not allowed to create classes in java.lang.*
2)  Using getDelclaredMethod to call "add( Thread )" in the Threadgroup class
      -- fails, as I am not allowed to call getDeclaredMethod
3)  Use two piped streams to redirect system.err to an inputstream, so that I can have a thread watching this stream
      -- fails, as I am not allowed to redirect System.err

Basically, I am coming up against SecurityExceptions each time I try to catch my unchecked exceptions...

Is there a way of hooking them?  Without signing my applet?  (hehe, I refuse to sign the applet so I can handle errors...it all works -- this is more of a nicety) ;-)

So, has anyone else got any ideas I can try?

Hope so :-)

Yours, lacking inspiration

Tim
0
TimYates
Asked:
TimYates
  • 6
  • 5
  • 3
  • +2
3 Solutions
 
jimmackCommented:
Listening (interested in "improvements" on Dr. Heinz) ;-)
0
 
girionisCommented:
 Hello Tim,

> 1)  Subclassing ThreadGroup to allow me to add the currentThread to my own ThreadGroup
>(like he has)
>   -- fails, as I am not allowed to create classes in java.lang.*

  not sure if I understand this. Why do you have to create a class in java.lang package? Can you not subclass ThreadGroup and put your class in another package?
0
 
TimYatesAuthor Commented:
Ahh, no, becuase I was trying to add the current thread to my newly created threadgroup and;

    ThreadGroup.add( Thread ) ;

has default (package) access...  So I tried creating my class as

    java.lang.ExceptionThreadGroup

so that I could make the add method public...

Can't be done with an applet though...  Heh, and as it's not public, I'm not sure it's a good thing to do anyway ;-)

Tim
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
TimYatesAuthor Commented:
In his code he does:

---------------

public static void main(String[] args) {
    ThreadGroup exceptionThreadGroup = new ExceptionGroup();
    new Thread(exceptionThreadGroup, "Init thread") {
      public void run() {
        Gui gui = new Gui();
        gui.pack();
        gui.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        gui.show();
      }
    }.start();
  }

---------------

But as I don't create the thread, I cannot do this :-(  This applet is put into a ThreadGroup by the browser's jvm...

I *thought* I might be able to hack the Thread out of on threadgroup and into mine by subclassing ;-)

Hehehe...denied!

Tim
0
 
girionisCommented:
 Ahh... I see, wasn't sure about the access level of the add() method :)
0
 
TimYatesAuthor Commented:
Ooooh...

http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)

But that's part of Tiger (JDK1.5) :-(

And I'll bet that:

--------
Throws:
    java.lang.SecurityException - if a security manager is present and it denies RuntimePermission ("setDefaultUncaughtExceptionHandler")
--------

Will still throw a SecurityException if my applet isn't signed :-(

Bah...what with this, AND not being able to make my own URLClassloader that uses getCodebase() as it's url, the SecurityManager's really starting to tick me off ;-)

Hee hee

Still interested if anyone can think of a 1.4 way to do it (or a new direction for me to try) :-)

Tim
0
 
jimmackCommented:
Have you considered an e-mail to Heinz Kabutz?  He seems to thrive on feedback/questions like this ;-)
0
 
TimYatesAuthor Commented:
Ooooh...that's a good idea :-)  I'll link this page in too, to see if he fancies responding here :-)
0
 
girionisCommented:
 You might as well sign the applet :)
0
 
TimYatesAuthor Commented:
:-(

I don't want to spend £300 just so it can send me nice Exception reports ;-)

I'd rather talk people through the "copy it out of the java console" method on the phone...

hehehe
0
 
heinzkabutzCommented:
Hi ppl,

Two approaches spring to mind, another a third issue one needs to consider:

Approach 1. You could set the system property "sun.awt.exception.handler" to point to your own exception handler class.  Read the EventDispatchThread class and you will see that this is a temporary hack.

import java.applet.Applet;
import java.awt.*;
import java.awt.event.*;

public class MyApplet extends Applet {
  public MyApplet() {
    System.setProperty("sun.awt.exception.handler", "MyExceptionHandler");
  }
  public void init() {
    Button b = new Button("Don't press me!");
    b.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {
        throw new NullPointerException("hahaha!");
      }
    });
    add(b);
  }
}


Here is the exception handlers, that could basically do anything that the security manager would allow it to do:

public class MyExceptionHandler {
  public void handle(Throwable t) {
    System.out.println("MyExceptionHandler.handle found the following: ");
    t.printStackTrace();
  }
}


Some issues with this approach:

A) This will only work with Sun's JVM running the applets on the client machine.
B) Since that system property is protected, you have to convince the client to edit his java.policy file and add the following line:
    permission java.util.PropertyPermission "sun.awt.exception.handler", "write";
C) You have to be the first applet (I think) to set the property, since it is only checked once.
D) Besides these obstacles, this could be a solution in the case where you invite certain people to be your testers.  You cannot use this approach "en masse".


Approach 2. An approach that would definitely work, though I do not personally know how to do it, is to use a tool like BCEL or Aspect/J to adorn the methods in your applet to catch your RuntimeExceptions and to pass them to your handler.  This would not catch the spurious RuntimeExceptions that get generated from within the JVM, for that you would need Approach 1.  Another advantage with this approach is that it should work with any version of JVM, even the Microsoft one.


Issue 3.  One of the reasons why the ThreadGroup approach would be a bad idea in this scenario is that this approach is only possible since JDK 1.4.1.

Kind regards

Heinz
0
 
objectsCommented:
Heinz,

Out of curiosity in your article we didn't you use sun.awt.exception.handler to catch uncaught exceptions instead of subclassing ThreadGroup?
0
 
jimmackCommented:
Hi Heinz.

Just to say hello and welcome to EE (watch out, it can consume your life ;-))
0
 
heinzkabutzCommented:
Hi Jimmack & Co :-)

Yes, there is a good reason.  JDK 1.4.1 introduced the ThreadGroup approach to solving the problem.  I saw the event handler, but in the comments it spells out quite clearly that this is a hack that will be removed soon.  My logic was therefore (which I perhaps should've spelled out in the newsletter) that the ThreadGroup was the replacement for the event handler class name approach.

Regards

Heinz
0
 
objectsCommented:
understood, though my understanding was the hack would be replaced with a proper mechanism.

> JDK 1.4.1 introduced the ThreadGroup approach to solving the problem

i thought that was a bug fix :)
0
 
TimYatesAuthor Commented:
Thanks all!

Looks like signing it is the way to go...  As you can't do BCEL in an applet without signing it either...

As I already have my servlet which allows me to load classes on the fly from the server (http://www.experts-exchange.com/Programming/Programming_Languages/Java/Q_20715878.html), I will have to look into adding BCEL to it so that I can dynamically add try/catch blocks to the beginning and end of each method in the class, as it is loaded...

Then, no class files will exist on the server in the WEB-INF directory, they will just be on the classpath, and implement a coupld of Interfaces, to say that they are;

a) Loadable via the servlet
b) BCEL alterable :-)

Then, I can go through the ones that are BCEL alterable, and hack in the try/catch blocks as I stream the class to the browser JVM :-)

Woo!  Hack-tastic ;-)

However, that will have to wait until I have the website up and running properly ;-)  hee hee

Thank-you so much Heinz for replying here!!

Thanks again everyone!

Tim
0
 
girionisCommented:
 Thank you Tim, glad you found a work around (or shall I say hack?) it :)
0
 
girionisCommented:
 Oh, and BTW welcome Heinz :)
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 6
  • 5
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now