Question

i have some business logic that traps some logically invalid situations, e.g. trying to reverse a transaction that was already reversed. In this case the correct action is to inform the user:

Transaction already reversed

or

Cannot reverse a reversing transaction

or

You do not have permission to reverse transactions

or

This transaction is on a session that has already been closed

or

This transaction is too old to be reversed

The question is, how do i communicate these exceptional cases back to the calling code, so they can show the user?

Do i create a separate exception for each case:

catch (ETransactionAlreadyReversedException)
    MessageBox.Show('Transaction already reversed')
catch (EReversingAReversingTransactionException)
    MessageBox.Show('Cannot reverse a reversing transaction')
catch (ENoPermissionToReverseTranasctionException)
    MessageBox.Show('You do not have permission to reverse transactions')
catch (ECannotReverseTransactionOnAlredyClosedSessionException)
    MessageBox.Show('This transaction is on a session that has already been closed')
catch (ECannotReverseTooOldTransactionException)
    MessageBox.Show('This transaction is too old to be reversed')

Downside for this is that when there’s a new logical case to show the user:

Tranasctions created by NSL cannot be reversed

i don’t simply show the user a message, and instead it leaks out as an unhandled excpetion, when really it should be handled with another MessageBox.

The alternative is to create a single exception class:

`EReverseTransactionException`

With the understanding that any exception of this type is a logical check, that should be handled with a message box:

catch (EReverseTransactionException)

But it’s still understood that any other exceptions, ones that involve, for example, an memory ECC parity error, continue unhandled.

In other words, i don’t convert all errors that can be thrown by the ReverseTransaction() method into EReverseTransactionException, only ones that are logically invalid cause of the user.

Answer 1

I find that there are various broad categories of exception:

1. TransientException – what you just tried didn’t work, but if your try again it might. Used for cases such as Database not currently available.
2. InvalidRequestException – you just asked for something that can’t be done (Your examples fit here)
3. SystemException – The system is sick, we’ve forgotten everything you just said, your session is dead, you need to start all over again.

I would have these three main types of exception and catch each of them, there being obvious specific actions in each case. All my exceptions derive from these three types.