Ok, so I’ve changed our duplicate to work like Lucee does, where it s and deserializes the exception object instead of converting it to a struct. This should keep the detail key accessible. The tests are passing, but hopefully it doesn’t break anything else, lol

I also made our ParseException serializable, which will hopefully fix the other issue you reported to me via DMs.

Hmm, this is interesting-- neither Lucee nor Adobe actually give you a struct when duplicating a Throwable. They also don’t work the same.

The first dump for both engines outputs java.lang.RuntimeException as expected.

The second dump outputs coldfusion.runtime.ExceptionScope for Adobe, and java.lang.RuntimeException in Lucee. Lucee seems to actually just duplicate the throwable and creates a new one.

Perhaps if I can match the Lucee behavior, then the “fake” keys will still continue to work as expected because we’ll never actually convert it to a struct.

Ah, this is completely different! You are not attempting to access the detail key on a Throwable. You are duplicating the keys of a throwable into a struct and then accessing the detail key on the struct! This, of course, won’t work. While we’ll happily spoof fake fields like detail or extendedInfo on a throwable, once you duplicate it into a struct, then you’re stuck with whatever keys were actually there.

As you can seen here, this is the full repro case for this ticket:

I’m really curious what the point of duplicating the throwable is? duplicate() is a rather dangerous BIF to call and can even cause memory issues on large objects due to how it works. Wouldn’t it be better to just use the throwable directly in this case?

That said, I suppose we could modify the duplicate() BIF to add in the other keys so they always exist in the struct, even if they were never really in the Java throwable.

Well I have this code and “stException.detail“ is missing:

That is a java exception that comes from the JVM, not one thrown from boxlang. java exceptions have no concept of a detail key so showing it in the dump would be pointless as it would always be empty.

You can see that all exceptions that come from BoxLang have a detailkey

That said, even though a native java exception doesn’t have a detail, we will never error if you attempt to access it. ctcatch.detail will never throw an error and will just return an empty string for native java exceptions.

Did you encounter some sort of actual error from this, or did it just surprise you to see it wasn’t present in the dump.