Adding exceptions

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #5615
    Levi
    Participant

    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

    #5616
    Bob Mulvey
    Keymaster

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

    #5617

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

    #5618
    Levi
    Participant

    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

    #5619
    keithbrown
    Keymaster

    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.

    #5626

    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?

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.