Java becomes a slightly harder language to learn, because now there is one more thing to explain to a beginner: "Where exactly should super() be put in the constructor? At the start, in the middle, or at the end? What are the benefits and downsides of each, and when does it matter? Is there a convention?"
I think python is a classic example of this - python 2 was pretty simple. Python 3 just gets more and more complex.
the parent class however now has to deal with an arbitrary set of operation that the sub class can perform between the initializer block and the constructor method, so it's contract is overall much harder to define, because you can no longer be sure of your internal state in the constructor.
Edit- from reading https://stackoverflow.com/questions/25007427/how-are-excepti... it appears my suspicion was correct. try{ is effectively an annotation that has no impact on the sequence of instructions you are authoring. So it's surprising to me that it breaks the this/super first rule.
OTOH it seems to me there should always be a rule to not allow execution paths that never call super nor this, and since try could break that one I'd always be leery of using it in constructors.
> try { } Blocks
> The restriction that super() and this() may not appear inside a try { } block comes from the JVM itself, and is due to how StackMaps are represented. The logic is that when a superclass constructor throws an exception, the new instance on the stack is neither fully uninitialized nor fully initialized, so it should be considered unusable, and therefore such a constructor must never return. However, the JVM doesn't allow the bytecode to discard the unusable instance and throw another exception; instead, it doesn't allow it to exist on the stack at all. The net effect is that constructors can't catch exceptions thrown by superclass initialization, even if rethrown. [emphasis mine]
Every expression that you call in super was called before it, obviously.
So you always was writing code like
MyCtor() {
int arg1 = calcArg1();
int arg2 = calcArg2();
super(arg1, arg2);
}
Right now the rule is simple as it should be: you can't read `this`, explicitly or implicitly, before calling `super()`. Now it actually makes sense.
The only somewhat confusing thing about this JEP is that you can initialize fields before calling super. I don't see why this is needed and I'd treat it as code smell. I've read that example and I don't think that it's convincing. This code should be rewritten.
class Base {
public int Count { get; set; } = 0;
public Base(int counter) {
Count = counter;
}
}
class Sub : Base {
public Sub(int number) : base(number) {
System.Console.WriteLine($"This is the sub class constructor with {number} as an argument");
}
public Sub() : this(123) {
System.Console.WriteLine("This is the sub class constructor with no arguments");
}
}
It also makes the reason why you can do `super(fn1(), fn2())` but not extract those two calls to variables; these calls are considered to be part of a different part of the execution flow than the rest of the constructor. A simple `base()` can be left out, of course; it only matters in cases where you need a specific super constructor.
I would love something akin to this JEP in C#, but I'd want it in a way that makes it very clear that you're executing code prior to the base class' fields being initialized.
Something along this lines of this
public Foo(int bar)
{
prector
{
var baz = bar * bar;
base(baz);
}
ctor
{
// Foo's constructor code
}
}