Issues
Allow exceptions to be nested
Description
Attachments
relates to
Details
Assignee
Zac SpitzerZac SpitzerReporter
Brad WoodBrad WoodNew Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Sprint
NoneFix versions
Priority
Major
Details
Details
Assignee
Reporter
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Sprint
Fix versions
Priority
Activity
Zac Spitzer2 October 2023 at 11:48
yep, seeing the caused by at the bottom, closing
Michael Offner2 October 2023 at 08:34
please confirm and close the ticket
Michael Offner2 October 2023 at 08:33
found another issue, in cause it says “custom_type“ instead of “application“, fixed this for this case and also other places
Michael Offner2 October 2023 at 06:59
there is nothing wrong going on, in your example you do not set a cause, you set a type, interface of the throw function looks like this
void function throw(string message, string type="application", string detail, string errorcode, string extendedInfo, object, cause)
.
what you are doing is throw(message:"Upseli dupseli", type:e)
, lucee is able to convert an exception to a string, what happens in this case. what you should do instead is
throw(message:"Upseli dupseli", cause:e)
.
Zac Spitzer12 September 2023 at 13:25Edited
seeing a slight bug in the output (error version number is there twice?
adapting the example
In other languages like Java, I can catch an exception that was thrown from another library or subroutine and throw a new exception of my own that describes at a higher level what failed but still includes the original exception.
Java code:
Note, the original exception object is passed into the constructor for the new error, so all those juicy details are not lost, but instead stored as the "cause" for my error. I am given the chance to generate a useful message that describes the context of the inner error without losing the original exception.
CFML doesn't allow me to do this and I am forced to cram the original message and stack trace into the detail of my new exception. <cfrethrow> doesn't help since it doesn't allow me to add my own message and stack trace.
Right now, the throw tag allows me to pass in an exception object, but it is mutually exclusive with the other parameters. I think the best solution might be to simply allow the exception to be passed into cfthrow alongside a new message, etc and it will become the nested "cause".
It would also be ideal if the "cause" would present itself the same way nested Java exceptions do so my code doesn't have to treat them differently. This would allow frameworks to easily display nested exceptions regardless of whether they came from Java or CF.
Note, I have put in this identical ticket for Adobe ColdFusion and would appreciate a consistent implementation
https://bugbase.adobe.com/index.cfm?event=bug&id=3842667