Question

Imagine I have a service that looks like this:

public interface MyAccountService
{
    boolean create( String user );
}

The method create performs several changes, namely (for discussion sake):

1. adds a message into a Queue
2. adds a row into several tables
3. creates a LDAP account etc…

Currently I collapse all the error messages into a single boolean return value.
Now internally if there is an error, I will log these for the support team.

e.g. a typical log of a failed user creation

creation of “alistair” account in the following (strict) order:

• add to table Foo: success
• add to table Bar: success
• add to LDAP: failed
• add to queue: success

This way, the tech support folks can decide how to repair the account.

What is the best practice for designing systems such that we can easily trace
the success/failure of a transaction (and repair it manually) ? Is returning
boolean & swallowing all exceptions a good design ?

EDIT : By swallowing exceptions, I meant not throwing them up the the caller. However I do log the exceptions, and translate them to a false/true return value.

Answer 1

You have 2 options on this one in my opinion:
1. Throw a custom exception with the list of the successes, thus the client of the
API can catch the exception and see what failed and then decide which action to perform.
2. Return an ENUM in which you reflect all the possible results of the outcome, thus again
the client of the API can decide which action he will perform.

Any way you must log all the problems your method encounters so it can be traced…
Exception and problem swallowing is a very bad practice.

I like more the custom Exception method, for the ENUM is more C like API..