Should command design pattern return status to the invoker?

Introduction

Laymen explanation

If you are writing software which acts on user command and you process the command synchronously, it can impact response time for other commands. Using thread, you can do something better, but it costs in computation and thread synchronisation.

What if you store command and process in asynchronous manner. Isn't it good? You can schedule commands when to fire, you can prioritise more important commands. Doesn't it sound wonderful.

One thing you need to decide, how to handle command failure in this case. This topic helps in this regard.

Technical explanation

Command design pattern is used to encapsulate command as object. This pattern in fact help to fire commands in asynchronous manner. Other advantages are batching, prioritisation etc. It provides object oriented approach for managing command. Command is self contained object in following manner.

It contains all data needed to process command

It knows how to execute command

So, invoker of command is just a dumb code which starts command. It needn't know anything about the command. In fact, this property of invoker allows to execute command anytime. But then handling command error is a challenge.

Think, if command returns error to invoker, invoker can't do anything specifically.

Then How to handle error?

For every program every time you apply the pattern, one of the things we need to think about is:

Am I adding more coupling to many commands and the clients for only some specific error cases?

Command pattern is used to decouple command with the caller. Command object is supposed to know how to execute it.

In case, command pattern returns status to caller, caller has less option to handle it. This is because of the way command pattern is designed. To recall, command pattern ensures that command contains all the info for execution of command. So, caller need not be aware of command internals. So, caller has little choice other than providing generic way to handling error. This couldn't be sufficient for many cases.

Considering above analysis, below approach could be a possible choice.

First attempt should be to explore the approach so that command object can handle error itself. In this case, command pattern need not communicate to the caller.

In case, command object can't handle error itself, then command object should publish the error. This could be done by notifying error (using observer pattern).

Reference

https://stackoverflow.com/questions/1154935/command-pattern-returning-status