如何在Java中使用Jena API处理查询的空结果

Question

I am using Jena API. Every thing works fine with me, except when query match (ie result of Query is null) is not found in an Ontology Model. Then nothing is displayed in Browser using servlet, and null pointer exception is displayed at console. ie given below. Can anyone guide me how to handle this null pointer exception? thank you.

Jun 04, 2014 3:37:22 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [main.DevInsta] in context with path [/FMOnt] threw exception
java.lang.NullPointerException
    at main.DevInsta.doGet(DevInsta.java:71)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:409)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1044)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:313)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

Answer 1

Initial Solution

At the time of this answer, the query string used in this question is not posted, nor is the code which is used around where the NullPointerException occurs. This is a first-pass at assisting with the answer.

My usual source of a NullPointerException when working with a QueryExecution comes from one of two places:

Aggregates

If your query is using GROUP BY x , but your data doesn't bind anything to x , you can end up with a ResultSet that looks like the following:

---------------
|  ?x  |  ?y  |
---------------
|      |      |
---------------

You can get an unexpected true result from hasNext() , and then a subsequent NullPointerException when attempting to retrieve elements. The solution is, for aggregate queries, to test if the first result's expected bindings contain any null values as well.

Optional

If your query includes an optional block, then it may not get bound for a particular solution, and you need to test for it:

SELECT ?x ?y {
   ?x rdf:type urn:ExampleClass .
   OPTIONAL { ?x urn:p ?y }
}

When you iterate over QuerySolution objects, the value returned by getting a variable may be null , and you need to account for it in your code.

WebService Help

One thing which I would suggest, if your ResultSet isn't very large, is to use a ResultSetRewindable (provided by ResultSetFactory.copyResults ). In your web application, if you use a decent logging library, you can test things like logger.isDebugEnabled() . If it is, you can print a diagnostic value for the query using ResultSetFormatter . This can be extremely useful when attempting to understand why your rendering of a query is giving you unexpected results:

final QueryExecution exec = ...;
final ResultSetRewindable r = ResultSetFactory.copyResults(exec.execSelect());
exec.close();
// Assuming slf4j
if( logger.isDebugEnabled() ) {
    final ByteArrayOutputStream results = new ByteArrayOutputStream();
    ResultSetFactory.out(results,r);
    r.reset();
    logger.debug("Rendering query solution:\n{}", results);
}
// Continue on like you normally would 

If you don't want to do this in general (maybe doGet is called far too often and/or your results are too large and/or this is a complex system where the error happens rarely), then you can always put a try{..}catch(..){..} -block around where the exception is occurring, and only print a copy of the results when this particular exception is triggered.