StereotypeEx and hop

[qwerty]

Ever since this Ex has been introduced it was claimed that it should be used instead of its still living predecessor without the Ex. Now, to my astonishment (or rather not), in V15.2 the stereotypeEx applied to an attribute is broken. i used to do something like

attr.stereotypeEx = "my_profile::some_stereo"

which worked well. Now I found out that in V15.2 this simply assigns NOTHING to the stereotype. Not a wrong one. Nothing. What actually works:

attr.stereotype = "some_stereo"

That finds the stereo from my profile and assigns it (also works with 13.5 so I go back to no-Ex here).

q.

[Geert Bellekens]

Are you sure you don't have a typo in the fully qualified stereotype?

Previous version tried to guess the stereotype, so I can imagine that "my_profile::sOmE_stEreO" used to work in 13.5, but not in 15.2

It also seems that the guesswork hasn't been disabled completely als assinging something to attr.stereotype still seems to use the guessing logic.

Geert

[qwerty]

Ooooppppssss and *blush*

We used to rename a part of the profile name from "Generic" to "General" and that still used the old format So in the elder EA it (erroneously) picked the desired stereotype (probably first removing the profile name and then doing a best match). So in the newer EA version it strictly ignores a wrong stereotype.

Come to think of that, EA lacks a concept of propagating exceptions upon such wrong assignments. They CAN raise exceptions as I found out in the past. But that's done only in a few places. The usual EA way is it just be silent (like when you have wrecked stereotypes in your diagram toolbox).

Oh well.

q.

[Eve]

Come to think of that, EA lacks a concept of propagating exceptions upon such wrong assignments. They CAN raise exceptions as I found out in the past. But that's done only in a few places. The usual EA way is it just be silent (like when you have wrecked stereotypes in your diagram toolbox).

Unfortunately, if we added an exception for that situation you would instead be asking why a situation that used to work now crashes. Adding exceptions to any situation that previously didn't throw them we can assume that old code doesn't handle the exception. So... boom.

It also seems that the guesswork hasn't been disabled completely als assinging something to attr.stereotype still seems to use the guessing logic.

I've said before that assigning to Stereotype instead of StereotypeEx is explicitly telling EA to guess.

[qwerty]

Well, the Ex-issue was my fault. But the exception handling is an EA design error. At some places exceptions are thrown but most don't. I know it won't be fixed, so I will not start any discussion. It's just that from time to time I have to get some air...

q.

[Geert Bellekens]

I agree that starting to throw exceptions suddenly won't make the API users happy.
But swallowing exceptions like that is also not helpful.

What if EA could write these type of exceptions to an error log of some kind? Or the system output, or something like that?

It wouldn't break any existing code, and it would still provide the feedback we require when something goes wrong.
Especially when dealing with MDG's that would be so useful. MDG's that fail silently are such a nightmare to debug

Geert

[Paolo F Cantoni]

I agree that starting to throw exceptions suddenly won't make the API users happy.
But swallowing exceptions like that is also not helpful.

What if EA could write these type of exceptions to an error log of some kind? Or the system output, or something like that?

It wouldn't break any existing code, and it would still provide the feedback we require when something goes wrong.
Especially when dealing with MDG's that would be so useful. MDG's that fail silently are such a nightmare to debug

Geert

Wot 'ee sed!

Paolo

[qwerty]

I'd vote for a new Repository attribute ThrowÈxceptions which, once turned on, would make what it says. Untouched EA can work the old way.

q.