Reputation: 2383
I have a three layers C# software : UI, Business, Database.
I have some business rules that I want to implement into my business layer. For instance, if two objects have the same name, the business layer needs to throw an exception to the UI.
My problem is that my application is multi language, and my business layer don't have access to my resource files. So my UI needs to catch the exception from the business layer, and decide what message it will show to the user.
I was thinking about creating a BusinessException class, with a property who tells the UI which key to take in the ressource file. Do you thing it a good way to do it? Or do you have better ideas? Thank you!
Upvotes: 0
Views: 2192
Reputation: 2383
I ended up with a mix of those two solutions. So I'm using only one class : BusinessRuleException. This class as a property "rule" which is a enum of all my business rules.
When my UI receive a BusinessRuleException, it can catch it, and than compare the "rule" to a ressource file and get a friendly message for the user. If the UI can't find a translation, it will only send the rule as is. So the user still have a change to understand what is going on.
It don't like the solution of a different exception for every different business rule, because it will end up with so much extra code, which doesn't help you understand what is the real work you class is doing.
Upvotes: 0
Reputation: 14386
The preferred solution is to create different exception types that represent the different errors, add any important data as properties to the exceptions and let the UI handle the user facing error messages.
This is ideal if you have a separate UI design team that wants to handle the text displayed to the user, including error messages. To be frank, developers tend to write good error messages for other developers but not for users.
Otherwise, embed some form of message ID in the exception that the UI can look up (as you suggest) or localize the error messages in the business layer.
Upvotes: 1