Adding exceptions

[Levi]

I recently undertook the task of adding a new first class model element to the BridgePoint editor — exception. This work was done as part of the effort to fully support the MASL modeling language. In MASL, a domain declares an exception, giving it a visibility and a name. Visible activities can then catch these exceptions and handle them. In BridgePoint, code needed to be added for creating exceptions, CMEs, persistence, graphics reconciliation, tree hierarchy, and a few other small bits. As it turns out, this changeset is a great prototype for what parts of the source need to be touched to add a model element. Take a look at the implementation note here: https://github.com/xtuml/bridgepoint/blob/testing/doc-bridgepoint/notes/8544_exception_ui_int.md

[Bob Mulvey]

Would you please post a link to the pull request too so the actual changeset can be easily seen?

[Lee Riemenschneider]

What’s the difference between an exception and (i.e.,) a bridge call to the LOG domain?

[Levi]

An exception provides the modeler an avenue to model exceptional behavior in the application itself. For example, a MASL analyst may model a domain Cellphone, a class Antenna, and an exception TowerUnreachable. A class operation acquireTower() on Antenna may raise the TowerUnreachable exception and handle it in a certain way, or let the caller of acquireTower() to handle the exception. Of course, the same behavior can be modelled with “if” statements and calls to the LOG domain, however exceptions add richness and meaning to the language.

Read more about exceptions in the reference manual here (starting on page 93):
https://github.com/xtuml/bridgepoint/blob/master/src/org.xtuml.bp.doc/Reference/MASL/LanguageReference/legacy/maslrefman.pdf

Note that this is the legacy manual, a detailed explanation of exceptions is not available in the current manual.

Here is the pull request associated with this work:
https://github.com/xtuml/bridgepoint/pull/155

[keithbrown]

While running the bp.core JUnit tests I also note that the rename tests are generated. This caused a new test to be generated for renaming S_EXP.

This requires that the testRename1 model in the models repository be updated to include an exception for the test case to use.

[Lee Riemenschneider]

The documentation refers to exceptions as a software architectural concept for use in (e.g.) checking array bounds. i.e., unexpected exceptions. The present way to handle such things in the MC-3020 is through marking, which is part of the architecture domain. Introducing architecture domain concepts into the action language is domain pollution.

Your example shows expected result handling for an event, which isn’t domain pollution, but as present mechanisms exist for handling expected failures, adding another adds complexity (richness and meaning???) to the action language. (I’m very glad OAL doesn’t already have the switch-case vs. if-else complexity.)

So…are the exceptions a replacement to current SW architecture mechanisms, or an addition to the OAL?

[Author]

Posts