Last updated on 2018-10-28
I am working lately with some C# libraries (won’t name the suspects as they are not alone in their crime) which for some unknown reason, expose only asynchronous operations. For example, let’s say I want to fetch a coconut from my palm tree. This method would be defined as:
public Coconut fetchCoconut(int id)
Simple, right? But let’s say this operation is long. You have to find someone willing to cling up the palm tree, pay him, help him, catch the coconut, etc. Or maybe this called is actually a call to a web service that may take some time (as happens in the library I am using). For this case you could implement a new method:
public Task<Coconut> fetchCoconutAsync(int id)
That would do the trick, right? Yes. The problem starts when the developers of the library decide that you should only use the async version of the method. Excuse me? Not only are you telling me how I should be coding, this has also a number of problems: First, now it’s now my job as a programmer to start handling something that works asynchronously. And while it may perform faster/better, it adds more complications to your code that many times are just not needed. Even if this just means adding a call to Wait or Result, it means more irrelevant stuff in my code. Second, when running in managed runtimes like IIS, calling Wait or Result may case deadlocks (this is exactly what happened to me today).
So please, if you are a library developer, please leave the async handling to us, your users. If we need to call something asynchronously, we will to it. But if not, don’t make us write ugly code just because you though that we should be calling your code asynchronously.
Be First to Comment