This should be true: isObject(anExceptionObject)

Done

If you like to further discuss this topic, please use lang.lucee.org, this is the wrong context to discuss this

Sigh. Pls go read the heading of the ticket.

I'm not suggesting it's supposed to be a struct. I'm suggesting it's not supposed to be a struct. it's supposed to be an Exception object. It can implement struct behaviour as well if you like, but that's another issue. Literally another issue (see below)

I think you're getting your tickets confused. There are two issues:

1. an exception is an object. It should behave like one (this ticket).

2. an exception kinda has struct behaviour, but then kinda not as well (the other ticket: LDEV-322). It looks to me like there's just a partial implementation of struct behaviour.

You maintain both can't be true (it has both Exception and Struct behaviour), but this is not the case. The problem is you've done half the implementation on both bits of work. If it's an object (which it ought to be: exceptions are always objects), then it needs to correctly behave like one (eg: isObject() returns true, etc. The class that represents the Exception could also implement the Struct interface, which would mean it would correctly behave like a struct, instead of only kinda behaving like a struct: structKeyExists() works, but .keyExists() does not.

Follow?

i did a short review, the class "CatchBlock" (class in question), this class implements already the interface "Struct" so it is already a struct, so there is nothing to here.

I meant to comment on this:

> implementing the struct interface makes an object a struct

Well, no, it doesn't. That is a really naive understanding of OO, and I can only presume it's lazy wording (or poor translation into English) on your part.

If there's a class C, and its entire behaviour is defined by interface I, it can be said that C is an I, sure. But it's still also a C even though it does not implement any behaviour beyond that which is defined in I.

So if there's a Struct implementation class and a StructAPI interface, a Struct is a Struct and it's also a StructAPI. There would quite possibly be no type references in the Lucee codebase expecting a Struct, but instead a StructAPI is expected (NB: I'm only using the "API" suffix here to make distinct the difference between the implementation and the interface).

Now if there's then a class A and it implements interface I, then it can also be said that an A is an I, but it cannot be said that A is a C simply because A implements the same behaviour as C. For one thing, it also implements all its own behaviour as well.

So if there's a class Exception (behaviour defined by ExceptionAPI) it might also implement StructAPI so that it can share behaviour (method names) with a Struct, and also be used where a StructAPI is expected (as function arguments or return types). This, however, does not make an Exception a Struct. It's still an Exception. It can also be used wherever an ExceptionAPI is expected, and it still has its ExceptionAPI behaviour. If some method was expecting a Struct (which would be bad implementation), then an Exception would not work.

If you're saying you're not re-implementing Exception objects as being actual Struct instances, then you've done the wrong thing. All the Exception class should be doing is implementing the StructAPI interface. But still be a discrete Exception class.

So they should pass both isObject(), isStruct() tests. And if there was an isException() test, they should pass that as well.

we will make sure the exception is a real struct and acts in every case like one including this function, so false is the right repsonse to this

It just means that your exception objects also need to implement the same interface as structs.
what makes it a struct and make IsObject return false, my point. implementing the struct interface makes an object a struct, implement the array interface a array, ...

In my opinion there should be no halfway solution, we tread the exception as a struct or not, anything between only cause confusion. i will also check how for example the Image object acts in this case.