Tag Archives: concurrency

Too many errors?

Udi Dahan wrote a very helpful and enjoyable paper in which he Clarified CQRS (command-query responsibility segregation). While explaining the benefits of CQRS he planted a somewhat disturbing thought in my mind:

We may be resorting too readily to reporting errors to our users.

In other words, we may be telling our users “There’s something wrong here. You deal with it!” too quickly, too often and too readily. In many cases, appropriate alternatives are fairly obvious and probably quite implementable.

(As a side note, many of these alleged error conditions can be traced back to the failure to plan for the concurrency of events and actions in real life (i.e. we’re not talking thread management here) as Udi pointed out. That’s something to think about in another post…)

Is calling a situation an error and reporting it to the user the easy way out? As developers, are we yielding our responsibility to achieve meaningful outcomes when processing user requests to readily? What do we fear in this context?

I resolve to question decisions to treat a situation as an error and report it to a user more thoroughly in the future. That may well take some courage.

 

 

Advertisements

You can’t hide from concurrency

There are libraries, frameworks, languages and runtime environments that seek to shield software developers from having to understand concurrency–or at least are said to do so. In my experience, this doesn’t work.

I’m all for making developers’ lives easier and sparing users the effects of concurrency-related implementation errors. But tool support gets us only so far: we might succeed in making concurrency-related concerns invisible to developers, but they still need to understand concurrency issues on a conceptual level–maybe doubly so if they’re invisible in code. Failing that, we likely end up with beautifully looking code that blows up in amazing ways at runtime.

Been there, done that, yet another t-shirt is being printed as we speak.