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]