try-catch-finally blocks in sequence diagrams

[yunwang]

What is the correct way to show java try-catch-finally blocks in sequence diagrams? Using "break" fragment?


Thanks

[TrtnJohn]

Not sure why you would treat an exception return any different than any other message.  Exception is just another possible return to any method call.  Typically, my sequence diagrams are language independent.  If your method returns an exception just add the instance of the Exception class to the diagram as a seperate lifeline and show that the class creates and returns the object to the caller when the exception occurs.

IMHO, creating a single diagram for all possible scenarios that tries to describe exactly how the code will work creates a huge mess.  I like to break down my Use Cases into scenarios and have a seperate diagram for each scenario.  Otherwise, I end up with so may fragments and conditions that the diagram is difficult to manage.

[yunwang]

Thanks for your reply. But my question is not how to show throwing an exception. My question is how to show catching an exception and do something within the catch block. I need to seperate the stims in a try block from stims in a catch exception block.

Example code:

  public void myMethod()
  {
       doSomething;

       try
       {
           doA();
           doB();

       }
       catch(NullPointerException e)
       {
           doC();
           doD();
       }
        finally()
        {
            doE();
        }
  }

[TrtnJohn]

I understand what you are saying.  But, I am not sure why you would want to show this level of detail in a sequence diagram.  The fact that the code is executing in a catch block is really an implementation decision.  Regardless, you can use an opt fragment as you stated.   But, I think that will start to make things very messy in complicated methods.  This is why I suggested using a sequence diagram for each scenario instead.  That way you can have a simple diagram for the basic path scenario.  And, you can add additional diagrams for each alternate path.  (Including one's where exceptions are generated and caught).

[yunwang]

Thanks

[Martin Terreni]

I'm not sure I can answer how to do what your asking, but I can tell you how we confront it.

1st - we do NOT model all possible sequnces, and exmption are , in most cases, not the most important.

any way I think Jhon is right that it should be trated like any other normal call. If you consider it this way I would recomend to use each sequnce diagram for one program flow only. this meaning you are either showing a flow in which the code works without throwing exemption or others in which it does. As Jhon wrote, attempting to show  that the running code is within a try-catch block in sequnce diagram is meaningless,
becouse the sequnce digram is ment to model diferent scenarios of program flow and not to model how the code will be implemented (as Jhon wrote).

if the flow scenario you are modeling is the one in which the code runs without exemption then it is irrelevant and if it is a scenario in which an exemtion is thrown than it is reflected in the diagram by definition.

I now my answer is more methodoligical then technical but I hope it helps.

[mchiuminatto]

Even I agree the recomendations given by MartinT and TrntJhon, and if you decide to model try-catch blocks in your sequence diagrams (at most I would do it just for my own defined exceptions), I believe the best way is to use an Alt fragment:
______________
Alt:My Operation
______________

{ no exception thrown}---------------------------------------------

  Object 1 -------> doA() -----------> Object2
  Object 1 -------->doB();-----------> Object2
{Thrown NullPointer Exception }-------------------------------

      Object 1 -------> doC() -----------> Object2
      Object 1 -------->doD();-----------> Object2
{true}-------------------------------------------------------

    Object 1 -------->doE();-----------> Object2
__________________________________________

Or you may choose to left out of the  Alt fragment the finally messages. TThis is how I would do it, doesn't means is the only and correct way to do it.

Hope it helps

[yunwang]

Thanks! This realy helps.