0

When is fine to use task.Result instead of await task..? i know is not recommended but there is some exception where its use is allowed? For example,if i use a task.ContinueWith is ok to inside de continuation get the result? wath will be the difference in this case if i use await?

var task = Task.Run(
           () =>
           {
                DateTime date = DateTime.Now;
                return date.Hour > 17
                    ? "evening"
                    : date.Hour > 12
                        ? "afternoon"
                        : "morning";
            });
        
        await task.ContinueWith(
            antecedent =>
            {
                Console.WriteLine($"Good {antecedent.Result}!");
                Console.WriteLine($"And how are you this fine {antecedent.Result}?");
            }, TaskContinuationOptions.OnlyOnRanToCompletion);
  • 2
    Why would you use `await` with `ContinueWith`? `ContinueWith` is for the pre-`async/await` era except for very particular use cases. Generally, if you can use `await`, you should not be using `ContinueWith` nor `Result` – Camilo Terevinto Dec 02 '21 at 09:09
  • 1
    Its ok to use result, when you know the task is complete, or when you absolutely know there is not going to be a deadlock. There are many more exceptions to this rule, which makes this question how long is a peace of string, when in short, just use await – TheGeneral Dec 02 '21 at 09:10
  • I never had a deadlock by using task.Result so i'd say its almost always safe to use. `.Result` blocks the current thread, so theoretically you can run out of threads / memory if you keep too many threads sleeping. Not that this will even happen unless you're going super enterprise mode. – Charles Dec 02 '21 at 09:13
  • 2
    @Charles `Result` absolutely can cause deadlocks, so that's poor advice. See here: https://stackoverflow.com/questions/17248680/await-works-but-calling-task-result-hangs-deadlocks. – Johnathan Barclay Dec 02 '21 at 09:14
  • 3
    @Charles That's terrible advice! Task.Result will cause deadlocks when used in applications that rely on a SynchronizationContext! Also, what do you even mean by "super enterprise mode"? Such thing doesn't even exist – Camilo Terevinto Dec 02 '21 at 09:14
  • "*how long is a **piece** of string*"* – TheGeneral Dec 02 '21 at 09:18
  • I am guessing "*super enterprise mode*" = care about applications working – TheGeneral Dec 02 '21 at 09:20
  • @Camilo Terevinto TeSo, as i know once you execute an await if you execute an await only the first time of will execute anything. Subsequent await are essentially the same as .Result. Although calling .Result is not recommended to use if it has not executed already. Is that correct ? – causeofhell Dec 02 '21 at 09:23
  • @Charles That's a super dangerous comment. It's like saying "I play Russian Roulette all the time and I've never been shot". It's not just "enterprise" software that can deadlock, even simple code can suffer. – DavidG Dec 02 '21 at 11:46
  • @DavidG i know its an Unpopular Opinion. I've been using .Result for years and have yet to see a deadlock. "If you are calling from UI thread, you will deadlock instantly" -> yeah just tried this, runs fine. But i'll make sure to run it on a dedicated thread in the future. Thanks for your concern everyone. – Charles Dec 02 '21 at 11:56

1 Answers1

0

“Async all the way” means that you shouldn’t mix synchronous and asynchronous code without carefully considering the consequences. In particular, it’s usually a bad idea to block on async code by calling Task.Wait or Task.Result. This is an especially common problem for programmers who are “dipping their toes” into asynchronous programming, converting just a small part of their application and wrapping it in a synchronous API so the rest of the application is isolated from the changes. Unfortunately, they run into problems with deadlocks. ... The Main method for a console application is one of the few situations where code may block on an asynchronous method.

https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/march/async-await-best-practices-in-asynchronous-programming

I think you might get away with in a console program, but my advice would be to stay away from it.

Mika Karjunen
  • 342
  • 4
  • 9