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
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
Listening (interested in "improvements" on Dr. Heinz) ;-)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.ExceptionThreadG
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
ThreadGroup.add( Thread ) ;
has default (package) access... So I tried creating my class as
java.lang.ExceptionThreadG
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
ASKER
In his code he does:
---------------
public static void main(String[] args) {
ThreadGroup exceptionThreadGroup = new ExceptionGroup();
new Thread(exceptionThreadGrou
public void run() {
Gui gui = new Gui();
gui.pack();
gui.setDefaultCloseOperati
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
---------------
public static void main(String[] args) {
ThreadGroup exceptionThreadGroup = new ExceptionGroup();
new Thread(exceptionThreadGrou
public void run() {
Gui gui = new Gui();
gui.pack();
gui.setDefaultCloseOperati
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
Ahh... I see, wasn't sure about the access level of the add() method :)
ASKER
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.SecurityExceptio
--------
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
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.SecurityExceptio
--------
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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 :)
ASKER
:-(
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Heinz,
Out of curiosity in your article we didn't you use sun.awt.exception.handler to catch uncaught exceptions instead of subclassing ThreadGroup?
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 ;-))
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.
Regards
Heinz
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
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 :)
> JDK 1.4.1 introduced the ThreadGroup approach to solving the problem
i thought that was a bug fix :)
ASKER
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 (https://www.experts-exchange.com/questions/20715878/Classloading-applets-and-plugins.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
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 (https://www.experts-exchange.com/questions/20715878/Classloading-applets-and-plugins.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
Thank you Tim, glad you found a work around (or shall I say hack?) it :)
Oh, and BTW welcome Heinz :)