I've seen this kind of pattern usually when working with web services.

Imaging the following piece of code:

public bool RunCommand()
    // .. Some logic ..
    return true; // success

Basically we have a method in a class that executes some logic, if this is successful it returns a true, if not a false. At first you would say this make sense, right?

It kind of reminds me the days when I was learning C :)

But this is just over-complicating things. Any client of this method will have to add a check.

if(RunCommand()) {
  // everything good

// Show user success message

} else {

// error!

// show user something went wrong


Why not just assume that the method is going to be execute successfully? If not just throw and exception! Then just handle that exception. Simple!

Just adding the true/false return for success/error is basically re-implementing exceptions. Well, it's even worse. Exceptions are explicit, they mean that something went wrong, they even have a custom error message. A boolean just means that.. a boolean: true or false, it's open to interpretations. When we get a false it could mean anything, no error message, no custom exception.

Also returning values from command methods is a bad practice. You should have two kind of methods: querys that return values but don't change anything in your system and commands that change something but return nothing! This is known as CQS or Command and Query Separation.