I have the simplest code using Files.walk:
Stream<Path> stream = Files.walk(Paths.get("C:\\"));
stream.forEach(f -> {
System.out.println(f);
});
This code throws
Exception in thread "main" java.io.UncheckedIOException: java.nio.file.AccessDeniedException: C:\Documents and Settings
at java.nio.file.FileTreeIterator.fetchNextIfNeeded(Unknown Source)
at java.nio.file.FileTreeIterator.hasNext(Unknown Source)
at java.util.Iterator.forEachRemaining(Unknown Source)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining (Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential (Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at devl.test.FindDuplicates.main(FindDuplicates.java:53)
Caused by: java.nio.file.AccessDeniedException: C:\Documents and Settings
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsDirectoryStream.<init>(Unknown Source)
at sun.nio.fs.WindowsFileSystemProvider.newDirectoryStream (Unknown Source)
at java.nio.file.Files.newDirectoryStream(Unknown Source)
at java.nio.file.FileTreeWalker.visit(Unknown Source)
at java.nio.file.FileTreeWalker.next(Unknown Source)
... 11 more
And the stacktrace points to stream.forEach(f -> {. Adding a try/catch before the code makes it to stop reading the files when the exception is thrown.
The thing is - I want the code to continue reading different files on drive C even though the exception is thrown.
It seems like somehow adding a try/catch inside the foreach would solve it - how do I do it (a try/catch on f -> {, not the System.out.println(f);)?
Please note that I tried to circumvent this by doing
Stream<Path> s = stream.filter(f -> !f.toFile().getAbsolutePath().contains("Documents and Setting"));
s.forEach(f -> {
But the same exception is thrown (even doing stream.filter(f -> false) fails).
EDIT: Please note that I don't want to re-throw an exception (like I was suggested). So using s.forEach(LambdaExceptionUtil.rethrowConsumer(System.out::println)) still fails with the exact stacktrace.
To ignore errors during recursive directory traversal you need to use walkFileTree with a FileVisitor that does error handling.
The stream based convenience wrappers (walk) simply terminate on the first error they encounter, you can't prevent that.
If the listing of directories is what you're after, then why not use DirectoryStreamPaths instead? See the doc here for more: https://docs.oracle.com/javase/7/docs/api/java/nio/file/DirectoryStream.html
Furthere you can use it in conjuction with Java8 and what's more the exception handling is quite good.
Related
My road traffic model is throwing null pointers with a very cryptic stacktrace:
Exception during discrete event execution:
NullPointerException
java.lang.NullPointerException
at com.anylogic.libraries.road.Car_xjal.g(Unknown Source)
at com.anylogic.libraries.road.Car_xjal.al(Unknown Source)
at com.anylogic.libraries.road.Car_xjal.a(Unknown Source)
at com.anylogic.libraries.road.Car_xjal.on_SegmentEndEvent_xjal(Unknown Source)
at com.anylogic.libraries.road.Car_xjal$SegmentEndEvent.execute(Unknown Source)
at com.anylogic.engine.Engine.n(Unknown Source)
at com.anylogic.engine.Engine.cl(Unknown Source)
at com.anylogic.engine.Engine$n.run(Unknown Source)
The null pointer also doesn't happen immediately, I am able to see the model run for varying lengths of time(60-800 model seconds).
When a breakpoint is created, it says the following:
The JAR file C:\Program Files\AnyLogic 8.8 Professional\plugins\com.anylogic.road_traffic_library_8.8.1.202210270952\lib\RoadTrafficLibrary.jar
has no source attachment. You can attach a source by clicking Attach Source below
It also occasionally throws the same error, but citing a different path("C:\Program Files\AnyLogic 8.8 Professional\jre\lib\jrt-fs.jar") as having no source attachment instead.
Any help is appreciated.
A couple days ago, I got a support ticket for this NullPointerException:
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract com.redacted.SalesResponsePagination com.redacted.StatisticsService.findSalesData(com.redacted.ConfStats) throws com.redacted.AsyncException' threw an unexpected exception: java.lang.NullPointerException
at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:389)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:579)
at ... (typical GWT + Tomcat stacktrace)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at com.redacted.StatisticsControllerImpl.replacePrices(StatisticsControllerImpl.java:310)
at com.redacted.StatisticsControllerImpl.findSalesData(StatisticsControllerImpl.java:288)
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.GeneratedMethodAccessor752.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)
... 33 more
Caused by: java.lang.NullPointerException
at com.redacted.StatisticsControllerImpl.lambda$replacePrices$27(StatisticsControllerImpl.java:317)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source)
at ... (typical stream.forEach stacktrace)
Now, this was an easy one because the exact line number for the NPE was in plain sight; all I had to do was go to StatisticsControllerImpl.java:317:
salesResponsePagination.getSalesResponses().parallelStream()
.peek(sr -> /*...*/)
.filter(sr -> /*...*/)
/*310*/ .forEach(sr -> {
final List<CartElement> sentCEs = DaoService.getCartElementDAO().getSentCEs(/*...*/);
if (sentCEs != null && !sentCEs.isEmpty() && sentCEs.get(0) != null) {
final CartElement ce = sentCEs.get(0);
// some more non-NPE lines...
/*317*/ if (sr.getCurrency().equals(ce.getPurchaseCurrency()) && sr.getPrice().equals(ce.getPurchasePrice().intValue()) && !ce.getCurrency().equals(ce.getPurchaseCurrency())) {
// Some currency exchanging
}
// Etcetera (about 12 lines more)
});
And replace the .equals() calls with Object.equals() to avoid the NPE (investigating the reasons why some sales were registered with a NULL price or currency came later). Test, commit, push, send ticket to QA.
However, the next day QA returned the ticket saying that the NPE persisted, and they included a new, almost similar stack trace:
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract com.redacted.SalesResponsePagination com.redacted.StatisticsService.findSalesData(com.redacted.ConfStats) throws com.redacted.AsyncException' threw an unexpected exception: java.lang.NullPointerException
at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:389)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:579)
at ... (typical GWT + Tomcat stacktrace)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at com.redacted.StatisticsControllerImpl.replacePrices(StatisticsControllerImpl.java:310)
at com.redacted.StatisticsControllerImpl.findSalesData(StatisticsControllerImpl.java:288)
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)
... 33 more
Caused by: java.lang.NullPointerException
This stack trace was exactly the same as the previous one, except for two things:
This call was using NativeMethodAccessorImpl instead of GeneratedMethodAccessor752. Compare:
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.GeneratedMethodAccessor752.invoke(Unknown Source)
vs
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
This one was missing the stack trace for the lambda. The line where the NPE happened was missing.
This threw me off initially. Why was the last part of the stack trace missing? I asked QA to re-test and re-attach the stack trace a couple times, until I got a complete one; however, the complete one I got in the end was based on GeneratedMethodAccesor once again.
Now, if I understand correctly, sun.reflect.NativeMethodAccessorImpl is used for the first invocations of a method, until JIT has enough info to generate an optimized accesor for that method in the form of sun.reflect.GeneratedMethodAccessorNNN.
What I don't understand is: if Native is using my code and Generated is using JIT's generated code, shouldn't Native show more info about my code, not less?
So my question is:
Why do lambda runtime exceptions thrown inside sun.reflect.NativeMethodAccessorImpl seem to be missing the lambda's stack trace?
Can this be a bug in JDK's source code? Especially when the very same exception thrown inside sun.reflect.GeneratedMethodAccessor includes the lambda stack trace without problem.
The following code manages to get a stack trace similar to the first one. I can force the use of NativeMethodAccessor or GeneratedMethodAccesor by running it with a sufficiently low or high first parameter, respectively (i.e. java test.Main 1 or java test.Main 30).
However, the lambda part of it is always present, whether using Native or Generated.
package test;
import java.lang.reflect.Method;
import java.util.stream.IntStream;
class MyOtherClass {
public void methodWithLambda(boolean fail) {
IntStream.range(0, 1000).parallel().forEach(k -> {
if (fail && k % 500 == 0)
throw new NullPointerException();
});
}
public String methodProxy(boolean fail) {
methodWithLambda(fail);
return "OK";
}
}
class MyClass {
public String methodReflected(Boolean fail) {
return new MyOtherClass().methodProxy(fail);
}
}
class Main {
public static void main(String[] args) throws Exception {
Class<MyClass> clazz = MyClass.class;
Object instance = clazz.newInstance();
Method method = clazz.getMethod("methodReflected", Boolean.class);
int reps = args.length >= 1 ? Integer.valueOf(args[0]) : 20;
for (; reps --> 0;) {
// Several non-failing calls to force creation of GeneratedMethodAccesor
System.out.println((String) method.invoke(instance, false));
}
// Failing call
System.out.println((String) method.invoke(instance, true));
}
}
Stack trace for the above code when using NativeMethodAccesor:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at test.Main.main(Main.java:36)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfInt.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.IntPipeline.forEach(Unknown Source)
at java.util.stream.IntPipeline$Head.forEach(Unknown Source)
at test.MyOtherClass.methodWithLambda(Main.java:8)
at test.MyOtherClass.methodProxy(Main.java:14)
at test.MyClass.methodReflected(Main.java:21)
... 5 more
Caused by: java.lang.NullPointerException
at test.MyOtherClass.lambda$methodWithLambda$0(Main.java:10)
at java.util.stream.ForEachOps$ForEachOp$OfInt.accept(Unknown Source)
at java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Unknown Source)
at java.util.Spliterator$OfInt.forEachRemaining(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.ForEachOps$ForEachTask.compute(Unknown Source)
at java.util.concurrent.CountedCompleter.exec(Unknown Source)
at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)
at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
EDIT: Just to be clear: I am not looking for ways to fix this NPE, nor ways to force the lambda's stack trace to print. What I want to know is the reason why the above happens: different implementations? A bug? Something to do with forEach()?
This might be an issue of JDK-6678999, “Stacktrace missing after null string comparisons”:
After comparing a string to null and catching the exception and repeating the operation, JVM starts throwing "stackless" NullPointerException (it occurs after 9000 loops but this is variable)
The evaluation of the issue is
When the server compiler compiles a method, the stack trace in an exception thrown
by that method may be omitted for performance purposes.
[…] If the user always wants stack traces, use the -XX:-OmitStackTraceInFastThrow option to the VM.
So, the option -XX:-OmitStackTraceInFastThrow may solve the issue.
Note that the bug report was against Java 6, but since it has been closed as “Won't Fix”, it may still be relevant, though you would have to replace “server compiler” with “c2 compiler” in the explanation now.
The use of NativeMethodAccessorImpl or GeneratedMethodAccessor… is not relevant to this issue, except that both have a common cause; a higher number of executions may trigger the optimizations.
I wonder about a Java error that is repeatedly occurs in MATLAB. It typically occurs when MATLAB is doing some heavy stuff with Java. This can for example be holding Ctrl + Z or Ctrl + Y.
I did by mistake erase the error message before I copied it, but I think that I can pass the core of the problem anyway.
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
...
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Why did this error occur? I have found some information about this from MATLAB r2007, this due to that Java Swing is thread unsafe and MATLAB lacked support to ensure thread safety. However, that is supposed to have been fixed in MATLAB r2008b. So why do I get it now?
Here is the full stack trace:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at org.netbeans.editor.BaseDocument.notifyUnmodify(BaseDocument.java:1465)
at org.netbeans.editor.BaseDocument.notifyModifyCheckEnd(BaseDocument.java:816)
at org.netbeans.editor.BaseDocumentEvent.redo(BaseDocumentEvent.java:336)
at javax.swing.undo.UndoManager.redoTo(Unknown Source)
at javax.swing.undo.UndoManager.redo(Unknown Source)
at com.mathworks.mwswing.undo.MUndoManager.redo(MUndoManager.java:255)
at org.netbeans.editor.ActionFactory$RedoAction.actionPerformed(ActionFactory.java:767)
at org.netbeans.editor.BaseAction.actionPerformed(BaseAction.java:259)
at javax.swing.SwingUtilities.notifyAction(Unknown Source)
at javax.swing.JComponent.processKeyBinding(Unknown Source)
at javax.swing.JComponent.processKeyBindings(Unknown Source)
at javax.swing.JComponent.processKeyEvent(Unknown Source)
at com.mathworks.widgets.SyntaxTextPaneBase.processKeyEvent(SyntaxTextPaneBase.java:1187)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Well, based on your stack trace, probably there isn’t any definitive answer to your question, as you have already seen in MATLAB's forum, but given this line, I think there's a possible explanation:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
...
at javax.swing.undo.UndoManager.redoTo(Unknown Source) // <-- here!
at javax.swing.undo.UndoManager.redo(Unknown Source)
at com.mathworks.mwswing.undo.MUndoManager.redo(MUndoManager.java:255)
...
UndoManager class keeps an internal collection of UndoableEdit objects. This collection is actually inherithed from its superclass: CompoundEdit.
The internal implementation of UndoManager#redo() and UndoManager#redoTo(UndoableEdit edit) looks like this:
public class UndoManager extends CompoundEdit implements UndoableEditListener {
...
public synchronized void redo() throws CannotRedoException {
if (inProgress) {
UndoableEdit edit = editToBeRedone();
if (edit == null) {
throw new CannotRedoException();
}
redoTo(edit);
} else {
super.redo();
}
}
...
protected void redoTo(UndoableEdit edit) throws CannotRedoException {
boolean done = false;
while (!done) {
UndoableEdit next = edits.elementAt(indexOfNextAdd++);
next.redo(); // NPE here?
done = next == edit;
}
}
...
}
Considering this implementation and given that Swing's Event Dispatch Thread (EDT) is prone to cause troubles, I think it's probably a threading issue between MATLAB threads and the EDT. Specifically speaking this MATLAB-invoked method could be the source of the problem:
at com.mathworks.mwswing.undo.MUndoManager.redo(MUndoManager.java:255)
Since you say MATLAB needs to do heavy work, it's not unreasonable to think this method is trying to redo some edit that might well not be available anymore or might not be available yet, due to synchronization problems with the EDT.
You can find the ~/.matlab folder which contains MATLAB settings, etc. Use ls -la to show all hidden files and folders.
Open a terminal and execute sudo chmod 757 -R ~/.matlab.
Similarly there is a folder, MATLAB, in Documents.
Execute sudo chmod 757 -R ~/Documents/MATLAB.
Now restart MATLAB without root privileges. It worked for me on Ubuntu 14.04 (Trusty Tahr) and MATLAB 2015a.
Hi I am using jena to read som rdf file:
InputStream in = FileManager.get().open(adress);
model.read(in, adress);
problem in second row which throw sometimes SAXParseException:
org.xml.sax.SAXParseException: Element or attribute do not match QName production: QName::=(NCName':')?NCName.
com.hp.hpl.jena.shared.JenaException: org.xml.sax.SAXParseException: Element or attribute do not match QName production: QName::=(NCName':')?NCName.
at com.hp.hpl.jena.rdf.model.impl.RDFDefaultErrorHandler.fatalError(RDFDefaultErrorHandler.java:45)
at com.hp.hpl.jena.rdf.arp.impl.ARPSaxErrorHandler.fatalError(ARPSaxErrorHandler.java:35)
at com.hp.hpl.jena.rdf.arp.impl.XMLHandler.warning(XMLHandler.java:225)
at com.hp.hpl.jena.rdf.arp.impl.XMLHandler.fatalError(XMLHandler.java:255)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.scanQName(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at com.hp.hpl.jena.rdf.arp.impl.RDFXMLParser.parse(RDFXMLParser.java:142)
at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:158)
at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:145)
at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:215)
at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:197)
so I want to do some try catch block. The problem is when I do this, compiler return:
exception org.xml.sax.SAXParseException is never thrown in body of
corresponding try statement
So how I can chatch this exception ? I know that I can catch just Exception but then I cannot be sure where the problem occurs
SAXParserException is a "checked-exception" meaning that the method signature is forced to declare it, if it throws. Obviously, the method you call does not declare it, so you cannot catch it.
It looks like Jena is actually wrapping that exception in an "unchecked-exception" (ie, an exception that extends RuntimeException). This exception is actually JenaException. So you could add a try/catch for a JenaException and then use getCause() to find the original error encoutered by Jena.
You should catch JenaException instead of the SAXParseException. And then try to get the cause that might be the SAXParseException.
If you are looking to handle problems with your RDF XML input, there is a more direct way using the error handler interface to the Jena reader.
on Windows systems. I get the following NPE with the FileChooser. It is a known bug that is not fixed by sun yet. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342301
Does somebody know a workaround to prevent this exception?
Thanks.
André
Exception in thread "AWT-EventQueue-2" java.lang.NullPointerException
at
javax.swing.plaf.metal.MetalFileChooserUI$IndentIcon.getIconWidth(Unknown
Source) at javax.swing.SwingUtilities.layoutCompoundLabelImpl(Unknown
Source) at javax.swing.SwingUtilities.layoutCompoundLabel(Unknown
Source) at javax.swing.plaf.basic.BasicLabelUI.layoutCL(Unknown
Source) at
javax.swing.plaf.basic.BasicLabelUI.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source) at
javax.swing.plaf.basic.BasicListUI.updateLayoutState(Unknown Source)
at javax.swing.plaf.basic.BasicListUI.maybeUpdateLayoutState(Unknown
Source) at
javax.swing.plaf.basic.BasicListUI$Handler.valueChanged(Unknown
Source) at
javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
at javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown
Source) at
javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
at javax.swing.DefaultListSelectionModel.changeSelection(Unknown
Source) at
javax.swing.DefaultListSelectionModel.changeSelection(Unknown Source)
at javax.swing.DefaultListSelectionModel.setSelectionInterval(Unknown
Source) at javax.swing.JList.setSelectedIndex(Unknown Source) at
javax.swing.plaf.basic.BasicComboPopup.setListSelection(Unknown
Source) at javax.swing.plaf.basic.BasicComboPopup.access$300(Unknown
Source) at
javax.swing.plaf.basic.BasicComboPopup$Handler.itemStateChanged(Unknown
Source) at javax.swing.JComboBox.fireItemStateChanged(Unknown Source)
at javax.swing.JComboBox.selectedItemChanged(Unknown Source) at
javax.swing.JComboBox.contentsChanged(Unknown Source)
In the bug report that you linked to, they also mention a workaround.
It seems to come down to calling the methods in a specific order.
Have you tried that?
A DESCRIPTION OF THE PROBLEM :
There appears to be an undocumented bad intereaction between
explicitely setting the UI and removing all file filters, even temporarily.
If the latter is done before setting the ui, trying to display a file dialog
will throw an exception but not if the ui was set prior to messing with
the filters. Maybe it is possible to make the code more robust against
this or to include a warning in the docs?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached program: it will not bomb. Then move the setUI
line to the bottom of the constructor and try again: it will.
So, now with registered account :)
The problem with these steps in the mentioned link is, that the look and feel and therefor the UI is set globaly in our software. So the UI is set before I'm able to manipulate the file filters.
Edit: Missunderstood the code for reproduction. The exampled works as mentioned. Thanks.
It looks like the workaround description says you should try to set the UI before manipulating the filters. Does this not work?
If that doesn't work, is it possible to create an instance of your manipulated FileFilters at the same point that you are setting your UI?