stevedlawrence commented on code in PR #908:
URL: https://github.com/apache/daffodil/pull/908#discussion_r1068362847


##########
daffodil-runtime1/src/main/scala/org/apache/daffodil/api/DFDLParserUnparser.scala:
##########
@@ -226,84 +221,22 @@ object DFDL {
   }
 
   trait DaffodilUnparseContentHandler
-    extends  ProducerCoroutine
-    with org.xml.sax.ContentHandler {
+    extends org.xml.sax.ContentHandler {
     def getUnparseResult: UnparseResult
-    def enableInputterResolutionOfRelativeInfosetBlobURIs(): Unit
+    def enableResolutionOfRelativeInfosetBlobURIs(): Unit
   }
 
   /**
    * Used in SAXInfosetEvent.causeError to identify when an 
unparseResult.isError is true
    */
   class DaffodilUnparseErrorSAXException(unparseResult: UnparseResult)
-    extends 
org.xml.sax.SAXException(unparseResult.getDiagnostics.mkString("\n"))
+    extends SAXException(unparseResult.getDiagnostics.mkString("\n"))
 
   /**
    * Used in SAXInfosetEvent.causeError to identify when an unexpected error 
occurs

Review Comment:
   Good points.
   
   I think the only difference between these two exceptions is that if the user 
receives a DaffodilUnparseErrorSaxException, it means the unparse failed and 
the user can call getUnparseResult from the content handler to get the 
UnparseResult and get the diagnostics. With the other exception, it means 
there's probably a bug in Daffodil. I'll make this more clear and remove the 
SAXInfosetEvent stuff from the .api.



-- 
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]

Reply via email to