How to modell exceptions

[hugelsb]

How I can model exceptions on an operation of a class? I would like to select one or more possible exceptions with the Project Browser to define which class will be thrown. I was thinking about Tagged Values, but then I have to write the ExceptionClasses manualy.
 
Thanks for any idea.

[Uffe]

Hi!


Here's a simple approach which allows you to represent exceptions thrown by your operations, but not to see them in browser or diagrams.

First off, there is a predefined stereotype "exception" which can be applied to a Class. Use that to represent your exceptions.

Secondly, create a UML Tagged Value Type (Settings - UML) as follows:
Name: throws
Description: Exception thrown by an operation
Detail:
Type=RefGUID;
Values=Class;
Stereotypes=exception;

Then, when you want to add an exception to an Operation, select the Operation and create a Tagged Value for it (either in the Operation's properties dialog or in the workspace's tagged values window).
In the popup dialog, select the "throws" tag from the "Tag" dropdown list (note that this disables the "Value" text field), and click OK.
Back in the tagged values window, the new tag "throws" has no value and its value field allows no manual input. Instead it has an ellipsis ("...") button, allowing you to select a Class with the «exception» stereotype.
You can create multiple "throws" tags on a single Operation. (There is a RefGUIDList tagged value type, which should allow multiple selections, but I haven't got that to work.)

Advantages to this approach:
- Quick to implement
- Works for RTF generation.

Disadvantages:
- Tags on operations are not visible in browser or in diagrams
- Limited use in MDA Transforms and code generation (since the templates assume each tag is uniquely named)
- There is no way to see whether or not a particular «exception» Class is used anywhere, which leads to maintenance problems (deleting a Class which is being used in a Tagged Value leaves the class GUID in the tag, which is very confusing).

The way around this last problem is to create an SQL Search as follows:
Name: Exception thrown - GUID
Query: select * from t_operationtag where Property="throws" and VALUE="<Search Term>"

Hope this works for you; if anyone has a more fully-fledged approach I'd be thrilled to hear it. I have noted that the t_operation table in the EA DB schema actually has a "Throws" column, but I haven't seen anything in it.

Cheers,


/Uffe

[Frank Horn]

Instead of tagged values you could use the "link to element feature" feature which was introduced with EA 7.5:

- Draw a dependency from the class containing the operation to the exception class;
- Give the dependency a stereotype "throws";
- link the dependency source to the operation.

Then you can easily trace which exception classes are thrown (those which have "throws" dependencies in the links tab).

[Makulik]

hi hugelsb and uffe,

just addtionally to what you've been writing. after being asked by a colleague i have found an article shouwing how to model exception handling (try/catch) in UML sequence diarams using an alternative fragment with compartments for the 'disruptable' section (try) and the exception handler sections (catch). look here to get a grip:

unfortunately EA doesn's support 'disruptable' as selection for the fragment type. i  don't know if this is s.th. IBM proprietary, i didn't find it in the UML 2.2 superstructure. but i like the idea of doing it like this.
may be it should be possible, to define your own sequence fragments types in EA.

wbr
g.

[Uffe]

I like Frank's Connector-based approach better than my Tag-based one.
Both use EA-specific functionality (connector-feature linking and GUID tags, respectively), but with Connectors you get diagram visibility and traceability, both of which are lacking when you use Tags.
I haven't tested MDA transformation or report or code generation, but I'm pretty sure the Connector model works better there too. My hat, Sir, is tipped.

Regarding the sequence diagram, you could use an "alt" fragment with one branch for each possible exception, and place that in an "opt" fragment labelled "Handle Exception."
If the exception handler only relates to some of the preceding Messages, they could be placed in a "strict" fragment labelled "Try - Catch" and which would also include the "opt" fragment.
The Message(s) before the "opt" fragment is the operation being "tried", and anything after the "opt" fragment is equivalent to a "finally" clause.

[Geert Bellekens]

You might also be able to use activity diagrams to model the usage of exceptions.
see http://edn.embarcadero.com/article/30169

Geert

[Frank Horn]

I haven't tested MDA transformation or report or code generation, but I'm pretty sure the Connector model works better there too.

I wouldn't be so sure about this, Uffe. In EA 7.5 there was no way to determine via code generation (or MDA) template or via API to which feature a connector is linked, and I don't see anything new in the current (EA online manual.