jadams-tresys commented on code in PR #1610:
URL: https://github.com/apache/daffodil/pull/1610#discussion_r2683176158
##########
daffodil-core/src/test/java/org/apache/daffodil/jexample/TestAPI.java:
##########
@@ -242,6 +243,20 @@ public void testAPI1_A_Full_SavedParser() throws Exception
{
assertNotNull(parser);
}
+ // This is a duplicate of testAPII with an incorrect ProcessorFactory path
+ @Test
+ public void testAPI1_B() throws IOException, ClassNotFoundException {
+ DebuggerRunnerForAPITest customRunner = new DebuggerRunnerForAPITest();
+ Debugger debugger = Daffodil.newDaffodilDebugger(customRunner);
+
+ org.apache.daffodil.api.Compiler c = Daffodil.compiler();
+ java.io.File schemaFile = getResource("/test/api/mySchema1.dfdl.xsd");
+ ProcessorFactory pf = c.compileFile(schemaFile);
+ DataProcessor dp = pf.onPath("/something/else");
+ assertTrue(pf.isError());
Review Comment:
This feels a little weird to me to create a DataProcessor object, but then
have to check the processorFactory object to see if the DataProcessor was
created correctly.
While I think it's important that isError() should work as expected, is
there any benefit in returning null vs allowing the SDE to continue up the
chain? From the standpoint of someone using the API I feel like I'd get more
useful information more quickly from just having the exception than having to
check for null, then dig into the processorFactory object if I wanted the
details.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
