I'm running Eclipse for Java. I created a DOM version of an XML file. Now I want to change an attribute of an element in the file. I called a method that called a method in the class that controls the DOM, and I got a dialog box saying "JDI Thread Evaluations has encountered a problem. Exception processing async thread queue" while debugging.
I'm a relative newbie at Java and have not come across such an error, and I have no idea what's causing it.
If anyone has any suggestions as to the cause of the problem and/or ways to fix it ...
Thanks so much!
Keep an eye on your "Watch" expressions - if you don't need them, remove them all. Sometimes certain watch expressions have caused this error message for me.
This might also explain why it happens to intermittently for people (sometimes they have watch assignments that cause the error, however restarting or removing the right watch can solve the issue without them knowing it.)
The Java Debug Interface (JDI) is part of the Java Platform Debugger Architecture. One apparent way to trigger this exception occurs when an object's toString() method carelessly returns null. You might want to try a different debugger, and it wouldn't hurt to validate your XML. As noted in comments, the problem may appear intermittently, suggesting a thread synchronization problem.
This error occurs quiet a few times when you debugging.
You can clean this up by removing all watch statements and all breakpoints and restarting Eclipse.
The problem can also occur if source lookup is incorrectly configured. For example lets say one wants to watch the expression foo.bar(). Now if source lookup is incorrectly configured, the debugger is unable to resolve the binding for expression foo (see this eclipse bug). Then the invocation of .bar() will fail with a NullPointerException.
This problem may occur if you have "Detail Formatters" configured for specific classes (in Eclipse: Java -> Debug -> Detail Formatters). Try to disable them.
This was replicated in eclipse when I was debugging the expression which reads: "", which is just an empty expression.
So, if you're getting this problem, one solution may be to check to see if one of your expressions is empty or similar, then aptly delete it.
Related
I'm modifying a java program to search through a specific folder and load plug-ins at runtime. The plugin code is working fine. I have created an UncaughtExceptionHandler to catch problems with plugins that weren't coded properly, and for the most part that works. Except for one issue (one so far, anyway):
The plugins need to have a class that implements a specific interface, so that the main program recognises them as plugins. If the developer misses one of the abstract methods, an AbstractMethodError gets thrown. It goes through my ExceptionHandler and I'm able to put up a message to the user indicating that there's a problem with the plugin. After that, though, the program just hangs. What I want is the program to continue going so that I can skip the rest of the plugin stuff, remove it from the plugin list, and let the user run the main program without it. I put a try/catch block directly around the call to the missing method, but the catch doesn't get executed. It just goes to the ExceptionHandler and then... I don't know where it goes.
This is my first attempt at exception handling so I'm sure I'm just missing something obvious. Any help would be greatly appreciated. Thanks so much.
The problem with exceptions that sub-class from the Error class is that most of them are not recoverable (in your case it's AbstractMethodError). As per the Error class java-doc:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
I.e. it's not guaranteed that the app is recoverable after an Error is thrown. Depending on how you load/execute that plugin there might be some workarounds. First of all, you could check the loaded plugin class via reflection (some examples) if there is an implementation of the needed methods before actually trying the exectuion - so you could catch/throw an Exception rather than get the Error and hang later.
If it's not an option, you could investigate further on what is actually hanging after getting that error by analyzing thread dump re
Taking thread dumps in production
In our application we encounter very sporadic run time exceptions which crash our message processors (which are stand-alone java processes running on Java 8). The processors, at the time of this exception, generally try to execute a web service call.
The exception are
java.lang.Error: Failed to create new instance of com.sun.xml.internal.ws.api.streaming.XMLStreamWriterFactory$1
at com.sun.xml.internal.ws.api.streaming.ContextClassloaderLocal.createNewInstance(ContextClassloaderLocal.java:63)
..
Caused by: java.lang.IllegalArgumentException: Unable to access unsupported property javax.xml.stream.isRepairingNamespaces
at weblogic.xml.stax.ConfigurationContextBase.check(ConfigurationContextBase.java:90)
The strange thing is, the whole application is running without errors 99.9% of the time: the above exceptions happen quite infrequently (ca. every couple of days). After a crash, the processors are restarted automatically, and again operate perfectly fine, until the same exception occurs again after a seemingly random interval.
So far we could not correlate this with any misbehavior on the part of the JVM or the host the application is running on.
Does anyone have any pointers as to why such an unsupported property javax.xml.stream.isRepairingNamespaces exception could appear sporadically?
We're running jdk1.8.0_66 on Red Hat 4.8.5-4. Web service interfaces are generated using JAX-WS.
Edit:
I can't share the classpath (lots of internal info, sorry). We do have the Weblogic full client in there though: wlfullclient-12.1.3.jar. It defines an XML factory via ServiceLoader
META-INF/services/javax.xml.stream.XMLOutputFactory --> weblogic.xml.jaxp.RegistryXMLOutputFactory
Where as xml-apis-1.4.01.jar (also on classpath) contains javax/xml/stream/XMLOutputFactory.class (related to the exception thrown in ConfigurationContextBase).
Could this be part of the problem?
You have to change the class path order. At first point all the axis2 jars and then point the weblogic.jar in class path. Hope it will solve your issue.
I encountered this problem yesterday after making some significant changes to my code. This particular post is the ONLY information I can find by googling this particular error -- always a bad sign. After hours and hours of fruitless deep debugging, comparing the original working version of the code with the new non-working version, I decided to start backing out my code changes to see where/when the problem originated. Well, after backing out pretty much every single code change, the problem was still happening. I finally realized that this problem was perhaps external to the code. It turns out that at some point, I had added an extraneous library: wstx.jar to my lib directory. Once I removed that lib, everything worked great. So apparently it was utilizing the wrong classes to try to perform this operation.
Not sure if that is of any assistance to you, but even if not, I thought someone someday might stumble onto this and find it to be useful.
I have a legacy java app written up by a previous developer. A bug has recently been found in it, and I've been given the task of fixing it.
Part of the problem is that there were never any error messages reporting from it.
By putting in a lot of logging messages, I finally narrowed it down to a specific line in the code - it's trying to run a method on a null object.
This is something that SHOULD have thrown an error into the log. Yet it hasn't. And even fixing this one, there's a lot of this problem in the code - assuming something will have a value when it doesn't. Every time I put in a data-verification for one, it fails somewhere shortly down the line for a very similar reason, and then I have to go through the hassle of putting in logging commands every other line again to finally narrow it down.
Why would a java program be silently failing instead of throwing errors? I can't seem to find any sort of setting suggesting that this is on purpose, but I'm really not even sure where to look for such a thing.
I used abort() In C to make my program crash. And debugger will trap this.
Maybe equivalent in Java should be exception. But Java also has very strict exception chaining policy, so using of exception for debugging purpose doesn't seem to be a good idea.
What should I use for this in Java? Intentional program crash for debugging purpose which can be trapped by debugger. (I am using Eclipse)
Update
It would be very nice if the code can be optionally opt-out on release build.
In Eclipse you can set debug points, and run in debug mode.
That said, there is a difference between a CheckedException (which must be caught by the calling function or passed up the chain) and an UncheckedException (which is closer to what you want). Throw the latter if you want to force a crash.
However, this is generally a bad way to program. You'll find better results using alternative means to catch the errors you want.
You can use assert(false). Assuming you're using Eclipse for the debugger, you can set Eclipse to break on specific exceptions (in this case, AssertionError). Make sure you enable assertions, otherwise it won't do anything.
Since you have to explicitly tell the JVM to enable assertions, I think this would count as "code [that] can be optionally opt-out on release build."
I do not know how to handle it in Eclipse. However, under JDB, this can be done by catching the Exceptions. Eclipse should have such an interface.
Using command line like this
"catch java.io.FileNotFoundException"
For details, please refer to here
When using GWT I get following warning:
Referencing deprecated class 'com.google.gwt.user.client.rpc.SerializableException'
While it's only a warning, it's dead annoying having to look at every single time I run the project.
The warning occours since my RPC throws java.lang.Exception, and thus never actually uses the SerializableException, but GWT isn't clever enough to figure that out.
Is there a option to turn off the warning, or fix this, besides compiling my own version of the gwt-user/gwt-servlet libraries?
Thanks.
Edit: To clarify, this is GWT 2.0, and the project is being run from the Google Plugin in Eclipse.
Someone on the GWT's Google Group suggested using SerializationException instead of just Exception. Although, the javadocs for SerializableException suggest that Exception should be fine too :/ Which version of GWT are you using?
Deprecated. As of GWT 1.5, Exception
implements Serializable and can be
used in place of this [SerializableException] class
Lombardi's blog has a discussion of why exactly this is happening in the source.
Yeah, it's silly for Google to claim throwing Exception is a fine thing to do when it generates a lot of unnecessary JavaScript for subclasses of Exception and, in your case, generates warnings about those subclasses.
But this is all the more reason to throw a more specific exception (one that doesn't have a deprecated descendant). Unchecked exceptions on your RPC can still be handled by an UncaughtExceptionHandler.
You could set the loglevel of the gwt compiler. It seems like you have set yours to "warn", set it to info to get rid of the message.
If you are using eclipse do the following steps:
right click on the project
Google >> GWT Complie
Set the Log Level to info
Although extending SerializationException is a workaround, the contract of SerializationException indicates that it should not be used as a parent class of your custom RPC exceptions. It's there to indicate issues with the serialization itself and not with the logic within your services.
The underlying issue is that the compiler generates unnecessary code. To avoid the error simply make sure that your code does not use SerializableException anymore and add the following line to your module descriptor.
<extend-configuration-property name="rpc.blacklist" value="com.google.gwt.user.client.rpc.SerializableException"/>
Once the compile issue is fixed, you can remove the line again. Here is a link to the issue you might wanna star/follow:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4438