File and line number lost when throwing the RootCause of a CFML exception

I’m porting an old (ACF 8!) app to Lucee 5. Its Application.cfc contains an
onError handler that deals with some circumstances itself, and in the
default case does roughly this:

> "onApplicationEnd"> > > > > > > >

(Yes I know it’s tags and shouldn’t be, first things first.)

In that default case, the exception reported points only to the
line, and no other CFML files are listed in the stack. That doesn’t happen
if it throws arguments.Exception directly instead.

Don’t think that happens with ACF, far as I can tell, but since the
particular exception I’m looking now at doesn’t happen at all on ACF, I
can’t be sure. I can say I’ve never seen an exception reported that way in
the ACF app, which has been used pretty heavily for years.

Is this expected behavior? Is there something I can do to improve the error
report, other than throw the original exception, let you dig to the
RootCause yourself?

Just to point out, recursively resolving RootCause is necessary in some
cases, to be able to identify some exception types we know how to handle,
like Security. Don’t have to throw that resolved version, but it somewhat
makes sense, and works on ACF.

DaveOn Thursday, January 19, 2017 at 10:12:40 AM UTC-5, Dave Merrill wrote:

I’m porting an old (ACF 8!) app to Lucee 5. Its Application.cfc contains
an onError handler that deals with some circumstances itself, and in the
default case does roughly this:

> "onApplicationEnd"> > > > > > > >

(Yes I know it’s tags and shouldn’t be, first things first.)

In that default case, the exception reported points only to the
line, and no other CFML files are listed in the stack. That doesn’t happen
if it throws arguments.Exception directly instead.

Don’t think that happens with ACF, far as I can tell, but since the
particular exception I’m looking now at doesn’t happen at all on ACF, I
can’t be sure. I can say I’ve never seen an exception reported that way in
the ACF app, which has been used pretty heavily for years.

Is this expected behavior? Is there something I can do to improve the
error report, other than throw the original exception, let you dig to the
RootCause yourself?