- Security wise, this message exposed sensitive implementation details to the user, on-screen. Mentioning system names, nature of exceptions to a user etc. is a risk. Any mischievous user could easily have used this information to their own benefit. It is these kinds of mistakes which can easily be avoided. The user should not be bothered with this kind of information. The ATM user is simply not concerned. A simple "Service not available" or "Service temporarily unavailable" message should have sufficed. The user is not interested in this information. A system administrator for example, should be concerned.
While we are at it, think about this one, It is not directly related to the issue at hand but it is a good practice anyhow:
Separation of technical exceptions from functional exceptions
What I encounter many times in my profession is that in the way exceptions are implemented, people often do not make a difference between technical and functional exceptions. This is related to the fact that technical issues (real exceptions) and functional concerns (not really exceptions) are easily intertwined - sometimes the conceptual difference between the two are ignored or not recognized leading to complex implementations.
A strategy I tend to follow is that both technical status and functional status are mapped into typically two separate fields. TECH_STATUS and FUNC_STATUS.
Whenever a service capability is to be executed, the response to any consumer would always contain a technical status. As the tech status illustrates whether something technically went wrong it is important to ie. both request-response patterns, as well is fire-forget.
The functional status however, may not always be available especially ie. when a fire-forget pattern is executed.
Some examples are listed below.
- tech status = service down for maintenance; func status = don't care/not available
- tech status = ok; func status = ok
- tech status = ok; func status = no data found
- tech status = connection not established; func status = not available
- tech status = ok; func status = not available
Obviously, a fire-forget pattern will not return a functional status as it will be executed offline from the consumer logic execution. Potentially a functional status may be returned asynchronously but this would not always be necessary. Sometimes it is sufficient to know that -eventually- the service core logic gets executed.
Hope you had fun reading; until next time...