Rethrown Exception Inside Transaction Being Wrapped In Application Exception
Description
Attachments
Activity
Jon Clausen8 hours ago
I have also reverted the initial commit that I thought would resolve the issue.
Jon Clausen8 hours agoEdited
OK. I figured this one out. It is coming from the exception being thrown inside of a transaction. The transaction component is the one wrapping the exception in another BoxRuntime exception - because we don’t have handling for a thrown custom exception. https://github.com/ortus-boxlang/BoxLang/commit/62d895d34aaaf5f9129ff5187348f85a71068d92 I have added handling to ensure that instances of BoxRuntimeException are rethrown as-is.
Brad Woodyesterday
why are we wrapping the exception on a rethrow?
When using the rethrow keyword specifically, the only time the exception would get wrapped is if it was a native java exception which was not a runtime exception (unchecked). In the case of a throw which originally came from CF in the first place using the throw tag, the exception would always be a runtime exception so it SHOULD never get wrapped. Can you get a repro case which shows this happening?
I can’t reproduce with this code:
try {
try {
throw( message="boom", extendedInfo="Extra")
} catch( any e ) {
rethrow;
}
} catch( any e2 ) {
println( e2.message ) // boom
println( e2.cause ) // null
println( e2.extendedInfo ) // extra
}The original exception is thrown cleanly without any wrapping.
Jon Clausenyesterday
@Brad Wood Yeah, I haven’t been able to create a simple repro case outside of the full chain of Coldbox/ContentBox. I will keep trying.
Jon Clausenyesterday
I have a feeling the throw in your last comment is getting caught and rethrown
Yes, it’s definitely getting rethrown, as that is the behavior of the bootstrap, which aroundHandler then catches and handles. The question then is, why are we wrapping the exception on a rethrow?
Jon ClausenyesterdayEdited
This is a pretty big deal for error logging as well as that extended info is what gets sent off to Sentry, Elasticsearch, etc.
Brad Woodyesterday
I have a feeling the throw in your last comment is getting caught and rethrown as it should be capable of having a cause since it doesn’t provide any other exception object. It’s worth noting, CF/Lucee doesn’t even allow a way to throw an exception with a cause as they make their object parameter mutually exclusive with all the other parameters. This is one of our BoxLang improvements. The code
throw( message="validation failed", object=e );will blow up on Adobe (it rejects any other arguments along side object) and Lucee will accept the object argument, but simply ignore it. So, I doubt we have code like that anywhere in ColdBox, or it wouldn’t work at all in Adobe CF.
Details
Details
Details
Sentry
Linked Issues
Sentry
Linked Issues
Sentry
Update: The original issue description was incorrect and was not the root cause of the issue. The issue was that the transaction component was re-wrapping the
BoxRuntimeException. Code sample updated:The following code produces a blank extendedInfo on the thrown exception inside of the transaction:
try{ transaction { queryExecute( "SELECT foo from bar" ); throw( message="foo", extendedInfo="bar" ); } } catch( any e ){ try{ throw( message="validation failed", object=e ); } catch( any j ){ result = j.extendedInfo } }