what is "base" in c# ?

public class RadBubbleBarMouseOverBehavior :

PropertyChangeBehavior

{

public RadBubbleBarMouseOverBehavior()

: base(RadItem.IsMouseOverProperty)

{

}

}

is a call up the super stack. It's basically SUPER().

This code would convert to:

In the ABL there's SUPER() and THIS-OBJECT() which are used to call up the hierarchy.

THIS-OBJECT calls the method in the current object (like RUN in TARGET-PROCEDURE); SUPER calls directly up the stack.

-- peter

Message was edited by:

Peter Judge

Isn't it confusing, that the call to the super constructor is outside of the classes constructor? I found that very confusing. But as Peter has written it's basically the same! The ABL compiler also enforces that the SUPER constructor is the first statement in a constructor.

The idea is that in C# and every other OO language that I know of (a short list) that the call to super MUST be the first statement in the constructor in order to enforce the initialization of the class in the super level of the class before anything is initialized in the current level of the class. So to avoid you having to think about it, the compiler enforces it through the use of additional syntax.

Methods do not have this syntax since you can put the call to super.method() anywhere in the body of the overriding or simply not call it at all.

So there's no big difference between OOABL and those other OO languages that we both know (short list for me as well) in this regard.

In some languages it's syntax enforced (like in this c# sample). In other languages it's enforced by the compiler (like in the ABL).

I wonder why the young OOABL syntax has not been copied here from those other languages. The SUPER:constructor call needs to be inside the constructor of the inheriting class. But for error handling etc. it's not really part of that block since you can't "ignore" an error thrown from the SUPER:constructor. Outside the block would have been clearer to indicate that.

Errors in the constructor are handled in one of two places.

Errors in the constructor are either handled by the constructor itself (or anything it calls). For instance, if the constructor calls a method that throws an expected exception then constructor or something in its call chain catches it and takes appropriate action.

The other place is the the error handling in the code for whatever method/procedure does a NEW object(). If any part of the constructor fails, then the whole object is invalid and the new statement fails and the assign does not take place. So you can suppress the exception by wrapping the NEW statement in a catch block and testing if the variable that you were assigning the new object is null/unknown. That of course depends on the logic of your code since you may want to propagate the exception.

Cool. thanks for the enlightenment

I was more thinking of the unhandled exception in the SUPER constructor or a custom error class trown in that constructor.

That exception (error) results in no object instance being created. The constructor of the inheriting class can't handle this error in a way, that it "ingores" it using a NO-ERROR statement or any catch block. The instance won't be valid.

There's no way to ignore the unhandled error in a SUPER-constructor and still receive an valid instance of the inheriting class, right? In a way, that would violate encapsulation.

The whole point is if any part of the super is invalid, then none of the derived code can possibly know the state of the super. Did it fail on line 20, or did it fail on line 23? Just because you might want to throw some custom exception that indicates exactly what part is invalid doesn't mean that someone else's derived class can know how to deal with that exception and "do the right thing" or maybe even know how to deal with a particular exception.

The ABL does not declare the exceptions that it throws in the syntax of the constructor or method. Java does this. Some people hate it some people love it.

The most common exception I see when dealing with constructors is an input object is null and the constructor validates this and throws some sort of exception indicating such as a protection mechanism to avoid an invalid object. A lot of times these input parameters are assigned to an internal private variable to which the derived classes have no access exception through perhaps a readonly property. If the derived class needs access to them, then it would hold onto them itself in its own private variables.

FYI... While it is true that an exception in a constructor can result in an invalid object remember that the default error handling in the ABL is to keep an error local and not alert the caller.

So unless the exception is that a class file cannot be found or it was called with the wrong number of parameters, a contructor will always "succeed". If you want the contruction of an object instance to fail, the contructor must explicitly return or throw an error.

-Shelley

I guess I can't spell conStructor?!

Message was edited by:

Shelley Chase