I personally avoid reporting errors with null return values, though that approach might actually be useful in some situations. I've seen cases where less-than-skilled developers had an irrational fear of exceptions and just treated them like undesirable error states instead of an error reporting and handling mechanism. It resulted in systems where every layer of the call stack was polluted with blocks such as:
if (result != null)
{
}
else ...
This usually results in the real cause of an error being completely and utterly lost somewhere in the call stack, as using this kind of binary approach to error reporting is inadequate to communicate what really happened.
Question:
How do you handle data concurrency issues in big multi-user systems? For instance, if your lowest level service (usually data access layer) throws a data concurrency exception due to some other user modifying the data that the current user is trying to modify, how do you communicate to your user that the data has changed and that they are supposed to refresh the web page, if you are masking the real cause of the problem by just returning null values from the lowest level of the call stack?
I personally handle cases like this by allowing the appropriate exception to propagate to the highest level so that I can make a judgment call whether it's the kind of error that needs to be reported to the user, silently logged or something else. On lower levels I still might have try-catch blocks for logging purposes and in certain situations I might rethrow exceptions if the error needs to be reported to a higher level.
if (result != null) { } else ...
This usually results in the real cause of an error being completely and utterly lost somewhere in the call stack, as using this kind of binary approach to error reporting is inadequate to communicate what really happened.
Question:
How do you handle data concurrency issues in big multi-user systems? For instance, if your lowest level service (usually data access layer) throws a data concurrency exception due to some other user modifying the data that the current user is trying to modify, how do you communicate to your user that the data has changed and that they are supposed to refresh the web page, if you are masking the real cause of the problem by just returning null values from the lowest level of the call stack?
I personally handle cases like this by allowing the appropriate exception to propagate to the highest level so that I can make a judgment call whether it's the kind of error that needs to be reported to the user, silently logged or something else. On lower levels I still might have try-catch blocks for logging purposes and in certain situations I might rethrow exceptions if the error needs to be reported to a higher level.