#5364 closed enhancement (fixed)
Obscure error message from NF
Reported by: | massimo ceraolo | Owned by: | Per Östlund |
---|---|---|---|
Priority: | normal | Milestone: | 2.0.0 |
Component: | New Instantiation | Version: | |
Keywords: | Cc: |
Description (last modified by )
Consider the following code:
model aaa parameter Real specificCons[:, :]( unit = "g/(kW.h)") = [0.0, 100; 10, 630]; equation end aaa;
When checked with the OF I get the following very clear warning:
[1] 17:42:45 Translation Warning [aaa: 2:38-2:55]: Non-array modification '"g/(kW.h)"' for array component, possibly due to missing 'each'.
When I check with the NF I get instead:
[2] 17:45:38 Translation Error [aaa: 2:3-2:79]: Type mismatch in binding unit = "g/(kW.h)", expected subtype of String[2, 2], got type String.
which, IMO, is worse.
What makes the second message worse, for me, is:
- the phrase "subtype of" (with basic types such as Real, Integer, Boolean, String are involved can this be omitted?)
- the absence of the hint regarding each.
Change History (11)
follow-up: 2 comment:1 by , 6 years ago
Component: | Frontend → New Instantiation |
---|---|
Milestone: | 1.14.0 → 2.0.0 |
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 6 years ago
Replying to casella:
@ceraolo, 'Subtype of XXX' is the technically correct description of derived types such as, e.g., SI.Units. Consider, for example
type Velocity = Real(unit = "m/s");which is a subtype of Real.I don't see a problem with that.
I think here we have a different situation.
It is just that String is a subtype of String. Removing "Subtype of", IMO clarifies.
comment:3 by , 6 years ago
Description: | modified (diff) |
---|
follow-up: 6 comment:4 by , 6 years ago
Well, any type is also a subtype of itself, the subtype relationship is not strict.
But I see your point. @perost, could we have a specific error message to display when the only thing that doesn't match in the bound type is the number of dimensions and their size? Could be something like:
Size mismatch in binding XXX. Expected array [2,2], got scalar.
In case the actual binding is a scalar and the expected one is any kind of array, you could add
Probably due to missing 'each'.
follow-up: 9 comment:5 by , 6 years ago
I will change the error messages as per your suggestions, and currently I have it so that e.g.:
model M Real x[3] = {1, 2}; end M;
will result in the error:
Type mismatch in binding ‘x = {1, 2}‘, expected array dimensions [3], got [2].
While e.g.:
model M Real x[3] = 1; end M;
will result in the error:
Non-array modification ‘1‘ for array component ‘x‘, possibly due to missing ‘each‘.
However, this:
model M Real x = {1, 2, 3}; end M;
will result in:
Type mismatch in binding ‘x = {1, 2, 3}‘, expected array dimensions [], got [3].
since that error is given when the base types are compatible but the dimensions are wrong. Personally I think using []
to denote a scalar is fine, but maybe you have a different opinion? I could trivially change it to give the old "expected subtype of" error when the component is a scalar instead, but I'd rather not add yet another error message just for this case. Besides, this particular case is quite rare in my experience.
comment:6 by , 6 years ago
Replying to casella:
Well, any type is also a subtype of itself, the subtype relationship is not strict.
That's what exactly I meant with the first dot of my ticket description and in comment 2!
So we finally agree on what we mean :-)
comment:8 by , 6 years ago
Description: | modified (diff) |
---|
follow-up: 10 comment:9 by , 6 years ago
since that error is given when the base types are compatible but the dimensions are wrong. Personally I think using
[]
to denote a scalar is fine, but maybe you have a different opinion? I could trivially change it to give the old "expected subtype of" error when the component is a scalar instead, but I'd rather not add yet another error message just for this case. Besides, this particular case is quite rare in my experience.
In think everything is much better now. As you noted, your latest example is slightly less self-explaining than the others. In case it is easy to change, I would prefer something like:
"expected array dimensions, got none"
Thank you.
follow-up: 11 comment:10 by , 6 years ago
Replying to ceraolo:
since that error is given when the base types are compatible but the dimensions are wrong. Personally I think using
[]
to denote a scalar is fine, but maybe you have a different opinion? I could trivially change it to give the old "expected subtype of" error when the component is a scalar instead, but I'd rather not add yet another error message just for this case. Besides, this particular case is quite rare in my experience.
In think everything is much better now. As you noted, your latest example is slightly less self-explaining than the others. In case it is easy to change, I would prefer something like:
"expected array dimensions, got none"
Thank you.
It's actually the opposite, i.e. no array dimensions were expected in the binding. A better message might be something like "expected scalar, got array", but that would either make the error message harder to translate or I'd have to add a new message for this particular case.
But I think it's clear enough that most users will understand what it means, so unless someone objects heavily I think I'll keep it as it is now. I also think that at some point it becomes more of a hinderance than a help to have unique error messages for special cases, since it reduces the chance that the user is already familiar with the error and knows what it means.
comment:11 by , 6 years ago
It's actually the opposite, i.e. no array dimensions were expected in the binding.
I see! I did not take into account that we a re going from left to right.
But I think it's clear enough that most users will understand what it means, so unless someone objects heavily I think I'll keep it as it is now.
Ok. Thanks again for considering this ticket.
@ceraolo, 'Subtype of XXX' is the technically correct description of derived types such as, e.g., SI.Units. Consider, for example
which is a subtype of Real.I don't see a problem with that.
However, I completly agree that if we can keep the hint about the missing 'each', when a scalar binding is found instead of an array one, this would be very helpful to users.
@perost, can you take care of that?