How to handle errors for a facade method that performs many disparate background changes ?

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 ? Thanks

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

It depends on the need.

If the exception is because of the wrong information sent by the client and you want them to know so that they correct it, then you should throw the exception.

If the exception is because of internal issue but still you want the client to know then throw the exception.

Answer 2

No it is not. All available information about the exception should be logged. (including but not limited to: Exception Type, Message, Stack Trace, ...)

Answer 3

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..

Answer 4

I like the approach described in the article presented here, there is a discussion about it here...

The idea is to consider to kind of exceptions, and to handle them differently:

One type of exception is a contingency, which means that a process was executed that cannot succeed because of a known problem (the example he uses is that of a checking account, where the account has insufficient funds, or a check has a stop payment issued.) These problems should be handled by way of a distinct mechanism, and the code should expect to manage them.

The other type of exception is a fault, such as the IOException. A fault is typically not something that is or should be expected, and therefore handling faults should probably not be part of a normal process.