Let's say you write a program that, when started, reads its configuration file to know which modules to start-up etc. If that configuration file is missing, an error will probably show up. This is an important situation that must always be handled.

I read a statistic once which said that about 70 % of the code in a typical program is there to deal with corner cases (like check that file is not missing, catch an Exception, check that I don't divide by 0, check that a person's age is a positive number etc.).

I don't believe this (i.e. the 70 % claim) to be very accurate, but then again, a lot of the code that I write contains a lot of ifs that check for valid parameters and stuff like that. I doubt I'm the only one who does this. So that statistic does have some truth in it.

If a big part of a program's code is represented by these checks, then shouldn't these cases be represented in UML diagrams ? (like sequence diagrams etc.). I can't remember if I ever saw such things.

Should I include them in my diagrams ? Will that enlighten or disturb/confuse another programmer who looks at those diagrams ? Would the diagrams then become too big because of this ?


INMO, you should define why are you using UML in your situation. If you are providing specification for someone to code from, then you may have to do that. If you want to specify step-by-step flow, use pseudo code not UML diagram.

If you are showing part of a flow as an example, yes, you could show all details (within a page or so). Also, if you have a tool that generates code from your definition then you need to do that.

If you are describing a process flow, then you may want to be generic about such details and represent all validation errors in 1 spot say, by using a comment that would apply to several of operations such as all file reads. The point here is to focus on the main scenarios not the exceptions.

In general, when you add low level details to diagrams, they become hard to read and take away the visual advantage a picture has over text. Also, with the exception of the Class Diagrams, UML diagrams are almost always presented in high level.

Whatever your choice is, follow it across all your diagrams. Consistency is important.

| improve this answer | |

I don't think so. UML diagrams don't generally show details that far down. You might outline your plan for exception handling in pseusocode somewhere, but you don't want to clutter your higher level diagrams with defensive programming details. I think that would be noisy.

| improve this answer | |
  • Not even at a high level ? (without details) – Radu Murzea Aug 10 '12 at 19:42
  • @sobolan Not really. If you have a class with a primary purpose of handling exceptions, you would show it, or an error page in a web app. But most exception handling is done at the method level and I wouldn't reference that on any uml diagram. When methods are listed in a class diagram it's assumed they check nulls, handle exceptions and that they will work. – Forty-Two Aug 10 '12 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.