It the exceptions thrown in case of error are represented in the UML sequence diagram, would it make the UML sequence diagram too heavy?
If they are not represented, how to tell about them?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this communityIt the exceptions thrown in case of error are represented in the UML sequence diagram, would it make the UML sequence diagram too heavy?
If they are not represented, how to tell about them?
Different diagrams show different perspectives, so showing them in a sequence diagram has value. It may not be sufficient to understand everything, however.
Craig Larman's Applying UML with Patterns book has an example in Chapter 35 showing exceptions as asynchronous messages (stick arrowhead). It's a pretty useful example. This figure is from the instructor's material:
The sequence diagram aims to show how objects interact in a given scenario. It is not meant to fully specify all the possible behaviors of all the involved occurrences:
But it could make sense in some cases to nevertheless show in a sequence diagram the scenario in case of a particular exception. For example when, due to complex interactions, it is not clear how the exception would impact the other involved occurrences in the scenario to gracefully recover.
In this case you could use a combined fragment of type break:
UML specs 2.5, section 17.6.3.9: ... represents a breaking scenario in the sense that the operand is a scenario that is performed instead of the remainder of the enclosing interaction fragment.
Rather than using SDs you should go for an AD which has Interruptible Regions to show exception handling (see bottom of https://www.uml-diagrams.org/activity-diagrams.html). It does not make much sense to (mis-)use diagrams if there are other diagram types having ways to express the things you want.