The fUML subset should support the raising and handling of exceptions
Legacy Issue Number: 15989
Source: Model Driven Solutions ( Ed Seidewitz)
Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14)
The submission team for the Alf action language felt that it was important that the action language be able to support exceptions, since existing class models in UML may include operations that raise exceptions and it should be possible to use the action language to specify methods for such operations without having to change how errors are reported. However, without exceptions being included in the fUML subset, the mapping of the raising and handling of exceptions in the action language to fUML was too complicated and probably semantically questionable.
Therefore, support for the raising and handling of exceptions should be included in the fUML subset so that it can properly be included in the surface action language notation.
Reported: FUML 1.0 — Wed, 26 Jan 2011 05:00 GMT
Disposition: Resolved — FUML 1.5
Add exception handling
The request to include exceptions in the fUML subset is one of the oldest that has not been resolved. As noted in the issue description, it was originally submitted against the FTF beta version of the fUML specification. Since then, the lack of support for exceptions has continued to be an impediment, particularly when using fUML for executable modeling for software. This lack often results in the use of poor workarounds, such as using "null" to represent an undefined or erroneous value, or other such "flagging" mechanisms – just the kind of things that exceptions were invented to avoid.
Further, exceptions are now also needed in fUML to support the proposed precise semantics SysML 1.7 (see https://issues.omg.org/browse/SYSML17-237), which will include an option in which constraint failure causes an exception to be raised. It is not considered feasible to add exception handling as just an extension for SysML 1.7 semantics.
And it turns out that adding exception handling to fUML is fairly straightforward, primarily just requiring a way to record the propagation of an exception up the call chain and new semantics for exception handlers. Specifically, this involves the following updates.
7. Abstract Syntax
- Add BehavioralFeature::raisedException. (Note that the UML specification does not give any formal constraints that would actually prevent the raising of exceptions not declared in the raisedException list. However, its inclusion would allow a tool to potentially do optional static checking for unexpected exception raising.)
- Add Operation::raisedException. (This is just a redefinition of BehavioralFeature::raisedException.)
- Add ExceptionHandler.
- Add RaiseExceptionAction.
8. Execution Model
- Update ExecutionFactory to add instantiation of RaiseExceptionActionActivation as the semantic visitor for RaiseExceptionAction.
8.8 Common Behavior
- Update Execution with semantics to propagate an exception raised during execution.
- Add (abstract) ExecutableNodeActivation with semantics for handling exceptions.
- Update ActionActivation with action-specific semantics for handling an exception.
- Update CallActionActivation with semantics for propagating an exception raised by the call execution.
- Add RaiseExceptionActionActivation with the semantics for raising an exception.
Updated: Fri, 18 Sep 2020 17:03 GMT
- 7.24-Executable-Nodes.svg 137 kB (image/svg+xml)
- 7.35-Other-Actions.svg 179 kB (image/svg+xml)
- 8.15-Executions-exception.svg 429 kB (image/svg+xml)
- 8.15-Executions.svg 546 kB (image/svg+xml)
- 8.35-Other-Action-Activations.svg 113 kB (image/svg+xml)
- BehavioralFeature.png 90 kB (image/png)
- ExecutableNodeActivation.png 76 kB (image/png)
- Operation.png 404 kB (image/png)