I have one exception handler class. I want to show this class in the uml — class diagram. But, I do not know how to represent relationship between class <X> and exception handler class. How can I represent relationship between class in class diagram?
0
From what I’ve seen, stereotype is usually used to represent the relationship to an exception.
a better approach would be to use UML’s stereotype notation with the keyword exception as the stereotype enclosed in guillemets, as in «exception».
Source: How can I represent an exception in UML?
This answer on Stack Overflow also suggests stereotypes, but uses <<throws>> instead. The author is confident that it’s ok to use a stereotype which doesn’t exist conventionally, and in this particular case, I agree with him.
As for the proper term, given that a stereotype can be a noun or a verb, both <<exception>> and <<throws>> seem equally correct. The proper terminology also depends on the language you use. For example in Python, you don’t throw, but raise an error or an exception, so <<raises>> looks as the most appropriate one; unless your intention is to separate errors and exceptions, in which case <<exception>> and <<error>> may be more expressive.
Finally, Agile Modeling suggests (search for Figure 4) to embed the name of the exception like this:
+ findAllInstances(): Vector {exceptions=NetworkFailure, DatabaseError}
but IMO, while it’s well suited for well-known exceptions used by the framework, it is too poor for custom exceptions you have created, because the relation is not visual enough.
One take on it is that the exception handlers are not a part of the problem domain, but rather a part of the non-functional requirements. That is, the architecture of the system. In that sense, they don’t really belong in a class diagram of a domain model any more than a Logger class belongs there. (Or a BeanFactory, or garbage collector, etc.)
Class diagrams display information about classes in the model as well as relationships between them. But an exception handler has a relationship with many or all of the classes — in that the control flow might suddenly halt and go to the exception handler instead. Worse still, the relationship between the exception handler and the domain classes is managed by the framework of the application, so there isn’t a direct relationship to the domain classes (by design).
If your class diagram is for the framework classes, then it’s easy. There will most likely be some sort of controller with a “has a” relationship to the exception handler. But if the class diagram is for the domain model, there are lots of bits from the background I wouldn’t put in the class diagram.