Menu
The ability to model the idea of catching an exception is pretty easy in a UML activity diagram - but what about THROWING the exception? The closest thing I can seem to find would be the throwing activity sending a signal with a stereotype of <<exception>> and then hitting a flow-final node, but I don't know that this is considered best-practice. Any thoughts?
Thanks.
778
Exceptions are shown either in activity or in sequence diagrams. Here an alt fragment is used where the upper part shows the exception behavior and the lower part the normal result. Note that this is a simple on-the-fly sketch. Action corresponds to a method in a class (given in brackets below the name).
UML provides neither notation to model exception handling in sequence diagrams nor any reasoning why it is absent. Some clumsy approaches to model try-catch blocks are by utilizing combined fragments - alt (alternatives) and breaks, while adding stereotypes for reply messages representing thrown exceptions.
Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The activity can be described as an operation of the system. The control flow is drawn from one operation to another. This flow can be sequential, branched, or concurrent.
UML 2.4 superstructure specification, in chapter 12.3.44 Pin (from BasicActivities, CompleteActivities), on figure 12.122 (page 416), you can see output pin for throwing exceptions. There is also an example on figure 12.129 (page 419).
177
UML notation exists to show exceptions. Look at Larman's book:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition By Craig Larman 35.3. Handling Failure Chapter
Larman says that :
*In summary, UML notation exists to show exceptions. However, it is rarely used. *This is not a recommendation to avoid early consideration of exception handling.* Quite the opposite: At an architectural level, the basic patterns, policies, and collaborations for exception handling need to be established early, because it is awkward to insert exception handling as an afterthought. However, the low-level design of handling particular exceptions is felt by many developers to be most appropriately decided during programming or via less detailed design descriptions, rather than via detailed UML diagrams.*
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
