Issues

Select view

Select search mode

 

Allow exceptions to be nested

Fixed

Description

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

Attachments

3

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

Created 22 July 2015 at 19:03
Updated 2 October 2023 at 11:48
Resolved 2 October 2023 at 11:48

Activity

Show:

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:25
Edited

seeing a slight bug in the output (error version number is there twice?

adapting the example

Flag notifications