mbeckerle commented on code in PR #1196:
URL: https://github.com/apache/daffodil/pull/1196#discussion_r1543274259
##########
daffodil-runtime1/src/main/scala/org/apache/daffodil/runtime1/api/DFDLParserUnparser.scala:
##########
@@ -236,8 +236,12 @@ object DFDL {
* Thrown by the DaffodilUnparseConentHandler when an unexpected error
* occurs, this usually represents a bug in Daffodil
*/
- class DaffodilUnhandledSAXException(description: String, cause: Exception)
- extends SAXException(description, cause)
+ class DaffodilUnhandledSAXException(description: String, cause: Throwable)
+ extends SAXException(description, new Exception(cause)) {
+ def this(msg: String) = this(msg, null)
+
+ def this(cause: Throwable) = this(null, cause)
Review Comment:
I recently discovered (today) that our SLF4J logging system doesn't properly
deal with constructors of Exceptions that take only a cause. If such a class
gets to top level you get "[error] null" where the null is because no message
string was supplied. So I recently changed some exception constructors to do
this:
def this(cause: Throwable) =
this({
if (cause.getMessage() == null)
Misc.getMessageFromClass(cause)
else
cause.getMessage()
},
cause)
This ensures if the exception object is passed to SLF4J's error method that
at least the class name of the cause shows up, and if the cause has a message,
that is used rather than 'null'.
This still doesn't deal with a bunch of chained cause exceptions where one
of them eventually has a message, or perhaps none of them do, but it avoids the
SLF4J 'null' output.
--
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]
