You model an exception through a Class that is derived from the java.lang Throwable Class. The Operation that throws the exception references the Class through the Java Throws tag definition.
The following example demonstrates how the Reverser reverse engineers exceptions, which is the way you should model exceptions in a model.
In this example, we reverse engineer the two files named Exception.java and Foo.java.
// File : C:/Code/Foo.java public class Foo { void Operation1() throws MyException { } }
When we reverse engineer the two files, we map the rt.jar library (which contains Throwable Java class) to a Package in the Model named JDK.
The Reverser creates the following items in the Model:
• The Throwable class for the Throwable Java class in the rt.jar library. The Throwable class is created in the JDK::Java::Lang package.
• The MyException class for the exception. The MyException class is a Sub Class of the Throwable class.
• The Foo class for the Foo.java file.
• The Operation1 operation for the Operation1 method. Operation1 is stereotyped by the «Java Method» stereotype and the value of the Java Throws tag definition references the MyException class.
If the rt.jar library was not mapped to the Model, the Reverser would not have created the Throwable class in the Model. Under these circumstances:
• The Reverser would then not have created the MyException class, therefore it cannot be referenced by the Operation.
• The Reverser would record the name of the exception (MyException) as the textual value of the Java Throws Text tag definition, which is applied to Operation1.
