> Testing the result of a constructor in any language is probably a dodgy practice. It's an object or it's a 'null'.
Ah, if there's an OO language anywhere that can return null from a constructor invocation, I have yet to see it.
There is a virtual class method to allocate memory and a so called constructor that initializes fields that should be zero.
The user of a class, only calls the constructor. The constructor then calls the memory-allocation method implicitly (you can see the call with a disassembler, but not in the Pascal code).
Anyways, you can override the memory-allocation method for each class. E.g. a useful case would be to build an arena allocator just for that class. But you can also override it, so that calling the class constructor returns a null
FWIW, it's also possible to enter an instance method with a null 'this' under certain circumstances (normally there would be a null reference check before entering the method body, but I've run into cases where there wasn't)
Contrived scenario: You AOT-compile your code in a 'no exceptions' mode, so the generated code assumes that malloc can't throw, etc. In that case if a failure happens during the 'new' process the only reasonable return values are either null or an instance with garbage data in it. As a compiler author, out of the two I'd probably pick null. This isn't as far-fetched as it sounds since right now exception handling in WebAssembly is a nightmare.
Actually, I wonder if an exception filter could observe the null before the unwind happens...