Should Error messages be returned by command Handlers?

[toeb]

Is it more usefull to throw an exception if a command is invalid or would it be better if the command gets a list of messages (info, warning, error) which the gui can then display

example.

when creating a transaction many things can go wrong, from argument null to invalid transaction balance.

I think it would be usefull if the command would get all information about why it is wrong so this could be displayed in the user interface?

A solution would be creating a command base class which contains a list of validation messages, possibly using a validation framework.

[matthiaszoellner]

Exceptions are a concept for 'out of scope' errors. If the caller fails to meet our interface, we should throw back an exception. We assume, that we (the business layer with commands) implement our own stuff without failure. So if we just want to sanity-check something, go with assertions. If something fails in Data/Model layer, the command may receive an exception. Out of scope would be something like "connection to database failed" but in scope would be something like "data constraints violated for operation X", since we have to meet interface requirements of lower layers.

Answered?

[toeb]

Validation is done lastely before an insert into the database (the command handlers are mostly validation code) Since the natural point of validation is here why should validation messages not be passed along to the upper layers?

[matthiaszoellner]

Seems I wasn't clear enough on that: if we (command) validate the input and find an error, we throw an exception back, since the caller provided us with bad data. If we deem the input valid and ask the datalayer to process the transaction and it fails, then we missed something in our validation - no need to throw exceptions about our problems to an upper layer.

[toeb]

The problem I have is that for any given command multiple things could be wrong. And it would be nice if every error is reported instead of the onlylthe current error (exception). So e.g. Account Name too long Account name already taken etc. would only be sent one at a time by the command handler. If validation were to happen separtely one could check the comand before executing it.

Have an IValidationService -> call Validate(cmd) -> returns validation result which contains all possible error messages, warning messages and info messages.

Command handler can then just call validate on cmd and if it has any error messages it will throw an exception containing all errors. else the command is executed -> separation of concerns since validation is needed by ui more often than exeution.

[matthiaszoellner]

How about having a validation service for primitives instead of commands?

ValidateAccountNumber(string) --> length, content restrictions, unique constraints, ... ValidateAccountName(string) ...

Under the hood, we would need this level anyway to validate the command contents.

[toeb]

I think some sort of automisation is requiered. Therefor using the type command type would be prefferable.

(von unterwegs)

Am 30.11.2014 um 13:42 schrieb matthiaszoellner notifications@github.com:

How about having a validation service for primitives instead of commands?

ValidateAccountNumber(string) --> length, content restrictions, unique constraints, ... ValidateAccountName(string) ...

Under the hood, we would need this level anyway to validate the command contents.

— Reply to this email directly or view it on GitHub https://github.com/toeb/accounting/issues/23#issuecomment-64984103.