Cannot trap exceptions in superclass constructor

[pokrakam]

Hi,

Scenario: A superclass has a constructor with an exception. In a subclass I also define a constructor. It helpfully generates the following code:

method CONSTRUCTOR .
**TRY.
*CALL METHOD SUPER->CONSTRUCTOR
*    .
** CATCH CX_STATIC_CHECK .
**ENDTRY.
endmethod.

When I uncomment the call method I get a warning that an exception is unhandled. When I uncomment everything, it throws a tantrum, saying <i>"You cannot call the constructor of the superclass conditionally"</i> and will not compile.

Is this supposed to work like this? Can one not trap exceptions? Nothing on OSS either. (Basis version 620)

Cheers,

Mike

[uwe_schieferstein]

Hello Mike

I believe the message is quite clear: If

CALL METHOD super->constructor.

fails then it makes absolutely no sense to continue with the CONSTRUCTOR method of any subclass (-> TRY - ENDTRY block). Thus, calling the CONSTRUCTOR method of a superclass is an <i>all-or-nothing</i> statement which cannot be made conditionally by using the TRY/CATCH block.

Regards

Uwe

[pokrakam]

Hello Uwe,

Partly correct: No it doesn't make sense to continue <i>instantiating</i> if the superclass fails but it does make sense to at least complete a try-endtry block to at least handle the error (ironically, as per the code it generates).

A superclass exception will always end up as an UNCAUGHT_EXCEPTION dump as I cannot do a catch-raise construct to pass the exception back to the instantiator of the subclass.

Thanks,

Mike

[Former Member]

> Is this supposed to work like this?

Yep.

This is not exactly an ABAP-Problem, it's an OO issue. There have been actually lots of disscussions about it. In Java for example, constructors have to start with a call to super(). The reason is simple: prevent modifications to instance-attributes of the sub-class before the object could have been initialized.

The problem with your code is that you try to catch the exception within the constuctor. Instead you should delegate it in the subclass-constructor and catch the exception on your "CREATE OBJECT sub." call.

[Former Member]

I agree with Hristo - but I want to take this discussion a step further. I don't think it is correct that any exception should be thrown from a constructor. That is not - in a "purist" view - what a constructor is for. Remember the main pupose of a constructor is to initialize instance variables. I know we all break this rule from time to time, but that is why the compiler is "surprised" to find a try - endtry around a contructor call.

[pokrakam]

Thanks for your inputs.

@Hristo: I don't get what you mean by "delegate it in the subclass-constructor and catch the exception on your "CREATE OBJECT sub." call."? I thought this is exactly what I'm trying to accomplish...? If the superclass constructor fails I want to catch the exception in the code that is trying to instantiate the subclass.

@Alistair: Interesting comment but I would disagree. This may or may not be be correct in a pure non-SAP OO context, but my context is a Business Class in a SAP environment. It is an object with a key, and the constructor's job is also to validate that I'm not trying to instantiate nonsense.

A simple example would be an order class with a subclass for a specific order type. The superclass constructor validates that the order number we're instantiating exists and the subclass validates that the order type is valid for the subclass. I cannot use parameters since I should not instantiate the object with invalid input data. Thus an exception is the only way to communicate a failure back to the instantiator. Or have I missed another ABAP OO concept that I'm supposed to be using here?

If nothing else then the generated code for a new constructor is misleading.

[Former Member]

Good Point Mike - the pure OO environment and the "real" SAP OO environment are sometimes very different

I think what Hristo is saying is put your CREATE OBJECT in a TRY...ENDTRY block rather than catching the exception in the constructor.

Hope that helps,

Alistair

[pokrakam]

Ah... figured it out!

In my tests I started out using cx_bapi_exception in the superclass and several days later in the subclass I used cx_bapi* -> F4 and ended up with cx_bapi_error - not realizing I used a different exception.

Since it dumped with <i>unhandled_exception</i> and I thought it was the same in both constructors, I assumed there was something special about CONSTRUCTORs causing exceptions not to propagate through to the caller.

Thanks all for the input though, it was an interesting discussion and I certainly learned a bit more about in-depth oo