CFCatch.type is not always a string

Description

Sometimes the type of a caught exception will not be a string, but a complex object. A lot of error handling code expects type to be a string which can cause errors.

See this example, which I tested in a CommandBox task runner that had a text file called "robots.txt" in the same dir. The exception is expected since the text file is not a valid zip, but the type is unexpectedly a complex value.

The output of this code is

You can see the e.type variable is an instance of the net.lingala.zip4j.exception.ZipException$Type class.

I'm running 5.3.4.59-SNAPSHOT but someone on 5.3.3.62 ran my test and didn't get the error, so this may be a regression.

Environment

None

Activity

Brad Wood 
5 December 2019 at 16:49

Thanks for the explanation and quick fix.

Michael Offner 
5 December 2019 at 16:06

Michael Offner 
5 December 2019 at 15:45

the reason for this is that the exception net.lingala.zip4j.exception.ZipException has a method “getType” and for native exception lucee takes in all getters of a Exception.

Pothys - MitrahSoft 
5 December 2019 at 07:56

I've checked this ticket and confirmed the issue happened on Lucee. The catch.type is not always a string format. In this case catch.type is a complex type value.

Fixed

Details

Assignee

Reporter

Priority

Labels

Fix versions

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

Affects versions

Created 4 December 2019 at 20:54
Updated 8 May 2020 at 18:52
Resolved 12 December 2019 at 13:22