This might be asked a thousand times but couldn't find the answer. I just wonder how you people handle the business logic errors? Im trying to do a nice api for my business model. Some methods have quite a lot of validation and I just wonder how should I report them if something goes wrong? Returning true or false or null sometimes won't say what was the actual cause. Sometimes it works sometimes it is not enough. I read that some people use exceptions. I've thought that I could return error messages and when everything goes fine then it would be null. Somehow error codes just don't add up for me..
Business Logic – Business Rules, Business Logic, Input Validation
businessbusiness-logic
Related Topic
- Database Design – Implementing Business Logic with Many Rules and Processes
- Business Logic – Understanding Business Rules, Processes, and Logic
- Business Logic – Organizing Complex Business Logic Rules
- CQRS Command – How to Validate and Transform to Domain Object
- Data vs business logic
- DDD and MediatR – Where to Place Validation and Business Logic
Best Answer
You are on the right track. Domain or business validation logic should do more than just report true or false. You want to enable the "user" of your business classes (ie the UI, or your logging system) to do something more than just report to the end-user that something is wrong.
Now, how you do that is completely up to you.
Decision to make: check everything and then report all errors/warnings/information, or stop at the first one you encounter. I would personally opt for the first one and let the UI decide how to use the info. There is a trade-off though: some validations may take longer than others and you may want to check these only if the "simple" ones succeed.
I wouldn't in any case use exceptions to do this. Some people use exceptions because most development environments have a nice way of showing any unhandled exceptions to the user. I think that is just a bad/lazy choice. And not just because it is then hard to decide where the error came from (though stack traces can help there), but also because it can(will) leave your app in an unpredictable state and may cause errors further down the line that will be even harder to debug.
Therefore, I tend to reserve exceptions for, well exceptional, circumstances. Things I didn't foresee. Validation doesn't fall into that category in my opinion - you did foresee all (current) validation concerns or you wouldn't have validated against them.
All in all, I code the validation in the domain/business classes to collect an array (or whatever I care to use) of error/warning/hint instances. They may be simple strings, they can be fully fledged classes. Usually I always return an instance to the caller and never an unassigned pointer. "Valid" is simplu indicated by a message count of zero.