2

I am currently adding functionality to a JSF/Richfaces application and we are now integrating with external web services.

Actions done with the services include: get user, get account, update user, update account, create user, create account.

These services, along with the unexpected soapfaultexceptions, can return error codes in their response types. Mainly for failures along the lines of: login already exists, password doesn't meet criteria, account number already exists, and no user found.

The calls are like so: BackingBean > Manager Level Class (mainly a pass through) > Web Service Client (makes the actual WS call). For the GET actions, the ID (username or account number) is passed down and the Account or User object is passed back up. The Updates pass around User/Account objects, same with the Creates.

What would be the best way to get these errors back up to the backingbean so I can handle them via the UI?

  1. Of course I could check for error codes in the response, throw an exception and keep throwing it to the backing bean where I would handle it there.
  2. I could implement a Result type that would hold an Error Type and POJO/DTO that I was populating from the service.
  3. One of my colleagues recommended I use the decorator to decorate my USER or ACCOUNT objects with validators that I would also need to create. Basically I suppose my decorator would just hold custom Error types and the Validate() would just check to see if (List!= null && !(Size>0)). Correct?

What are your thoughts on the proposed methods? #1 is the easiest, #2 seems to be more elegant and still simple, #3 is the "toughest" to me since I've never used the decorator pattern. However, #3 seems to be the most elegant while also being the most time consuming to implement.

Let me know if you need any more clarification.

Thanks, SO!

Nix
  • 57,072
  • 29
  • 149
  • 198
jkc
  • 112
  • 9

2 Answers2

1

It's always best to limit programatically using exceptions(When to throw an exception).

First ask yourself is this an exceptional situation? In your case it isn't its just a validation error. Exceptions come with a cost, and there is no guarantee that you will be able to catch the exception further down the chain.

Both 2/3 are similar solutions in the fact you are just trying to return additional information back to the controller.

Option 3, could be considered cleaner, but if you have access to the user/account classes, you could always add an additional property to the class that could contain validation errors.

A good example of this pattern is ActiveRecord within ruby, same type of model. You call save on a model object, if an error occurs it populates an error property.

Community
  • 1
  • 1
Nix
  • 57,072
  • 29
  • 149
  • 198
0

Throw a custom exception or one of a set of custom exceptions and handle it at the higher level. This is my preferred way of handling it versus status codes in Java where everything is pass by value, and frees up a return variable for other purposes.

In regards to "keep throwing it," don't catch and re-throw at each level, but only catch at the level where you can do something about it, ie. the backing bean / UI in this case.

Martin Smith
  • 76
  • 4
  • I tend to agree with @Nix that your error conditions, like failure to create a user because an account already exists, aren't truly "exceptional." – Martin Smith Apr 21 '11 at 16:43