JApplets, unchecked exceptions, and beautified reporting

Hi there!  Hope someone can help me :-)

I looked at this:


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

LVL 35
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Listening (interested in "improvements" on Dr. Heinz) ;-)
 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?
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


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 ;-)

CompTIA Security+

Learn the essential functions of CompTIA Security+, which establishes the core knowledge required of any cybersecurity role and leads professionals into intermediate-level cybersecurity jobs.

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();


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 ;-)


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


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

And I'll bet that:

    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) :-)

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

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!");

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: ");

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


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Mick BarryJava DeveloperCommented:

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

Just to say hello and welcome to EE (watch out, it can consume your life ;-))
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.


Mick BarryJava DeveloperCommented:
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 :)
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!

 Thank you Tim, glad you found a work around (or shall I say hack?) it :)
 Oh, and BTW welcome Heinz :)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.