How would you approach errors notification?

Question

Recently we had a discussion with my colleagues caused by my intentional attempt to generate user friendly message about occurred error (business logic) at the server side.

They insisted on putting all string localizable resources inside web client assembly and not server one. The argument is to let client decide how to generate and present messages to the user. I can't but agree with the requirement of such flexibility for public services, however we develop intranet back-office system and we develop client part as well (both thin and thick client). Frankly speaking the code I've seen so far does nothing more as generating the message (identical to the code I tried to put in BL). There is no particular controls highlighting, accurately positioned popups or something like that. But now the logic is duplicated: web client + win client.

My point is that It's better to adhere to DRY and YAGNI principles. Copy paste is evil.

The second argument is encapsulation. If error occurred inside Business Logic then it's BL who knows how to describe the error and what additional information should be collected and presented to the user without compromising security or revealing implementation details to the client part.

For example, in case of concurrent changes we return ConcurrenAccessError from the server and client then converts this to "bla bla bla, object was changed by someone else, edit once again, please." Now, to add user name and timestamp of the changes I need to extend ConcurrentAccessError class with additional properties and change code of message generation in two places. I would ask whether client should even know about concurrency as a special error type if it does nothing about it besides user notification. System is not designed for conflict resolving via merge. I believe that high granularity of errors is important only when such structured information allows system somehow help user to make corrections. (Highlighted and focused email input field is better than just a message below the form)

Well, eventually I did not manage to persuade my colleagues. I had to follow the conventions. Yet I need more pro and contra arguments to continue the discussion or agree with them.

I'd like to know which strategies of error notification you usually use and why. Where do you put the logic of constructing the message?

Answer 1

Every error should ideally inform its immediate consumer of a problem it can "understand."

Report errors from web services that developers and their client code needs to interpret. That means business objects sitting behind a web service don't contain end-user errors. Business objects shouldn't even know what interface is ultimately invoking them.

Client code, or whatever code sits "nearest to" to user should interpret lower level errors for and provide instructions to the end-user as-needed. Some errors don't need to be reported unless they recur.

My gmail, for instance, doesn't give me an onslaught of timeout errors when my connection goes down, it unobtrusively places a tiny string of text on the screen letting me know the server couldn't be reached, that's it's about to try again.

And while a connectivity error is a bit different than what you're asking, I think it illustrates the point: the client needs to know how to interpret lower level technical errors and tell the user how to deal with our ignore the problem.

Answer 2

I agree with @svidgen, server should process and probably log errors in a server way, UI should process errors and react on them in a user friendly manner, so the messages and code should probably reside on the client side. If you have two clients to you server (e.g. desktop client and web client) then you should stick to DRY and move the common client code to separate assembly used by both clients. Of course if it is internal application and you are 100% sure it will not need things like localisation, then creating this assembly solely for the purpose of generating error message is an overkill, but in general, both your clients could benefit of such a library.