We Keep Coding

Stuck with async await thread

In constructor I want to call one method type :
private async Task OnLoadPrometDanKorisnikDatum
and I want to wait that method while its finish, and I have more method(3) like this and I want to call this 3 methods in background thread and don't wait him to finish, just want to wait first method. And I want to them executing parallel.
I have methods async Task,and in constructor of view model I call like this
OnLoadPrometDanKorisnikDatum(KorisnikID, PomocnaDnDDatnaDat,
DatumVrednost).Wait();
OnLoadPrometNedelja(KorisnikID, PomocnaDnDDatnaDatNedelja).Wait();
if I don't place .Wait() on the end, program doesn't work. I see in debug mode they run asynchronly, but time spent tell me that they sub(one method time + second method time + ....).
Can someone help me, this is for me very stuf...

Answer
The best way to handle your scenario is to use async void.
I recommend first reading the Explanation section below to fully understand the best practices around async void.
public MyConstructor()
{
ExecuteAsyncMethods();
}
async void ExecuteAsyncMethods()
{
try
{
await OnLoadPrometDanKorisnikDatum(KorisnikID, PomocnaDnDDatnaDat, DatumVrednost);
await OnLoadPrometNedelja(KorisnikID, PomocnaDnDDatnaDatNedelja);
}
catch(Exception e)
{
//Handle Exception
}
}
Explanation
Many C# devs are taught "Never use async void", but this is one of the few use-cases for it.
Yes async void can be dangerous and here's why:
Cannot await an async avoid method
Can lead to race conditions
Difficult to catch an Exception thrown by async void methods
E.g. the following try/catch block will not catch the Exception thrown here:
public MyConstructor()
{
try
{
//Cannot await `async void`
AsyncVoidMethodWithException();
}
catch(Exception e)
{
//Will never catch the `Exception` thrown in `AsyncVoidMethodWithException` because `AsyncVoidMethodWithException` cannot be awaited
}
//code here will be executing by the time `AsyncVoidMethodWithException` throws the exception
}
async void AsyncVoidMethodWithException()
{
await Task.Delay(2000);
throw new Exception();
}
That being said, as long as we wrap the contents of our entire async void in a try/catch block, we will be able to catch the exception, like so:
public MyConstructor()
{
AsyncVoidMethodWithException();
}
async void AsyncVoidMethodWithException()
{
try
{
await Task.Delay(2000);
throw new Exception();
}
catch(Exception e)
{
//Exception will be caught and successfully handled
}
}
SafeFireAndForget
I created a library to help with this and its additional benefit is that it avoids writing async void code that could be potentially misused by future devs.
It's open source and also available on NuGet:
Source Code
NuGet Package
SafeFireAndForget
SafeFireAndForget allows us to safely execute a Task whilst not blocking the calling thread and without waiting for it to finish before moving to the next line of code.
Below is a simplified version of SafeFireAndForget that you can add to your project.
However, I recommend copy/pasting its complete source code or adding its NuGet Package to your library to get a more robust implementation
public static async void SafeFireAndForget<TException>(this Task task, Action<TException> onException = null, bool continueOnCapturedContext = false) where TException : Exception
{
try
{
await task.ConfigureAwait(continueOnCapturedContext);
}
catch (TException ex) when (onException != null)
{
onException(ex);
}
}
Using SafeFireAndForget
To use SafeFireAndForget, append it to your method call like so:
OnLoadPrometDanKorisnikDatum(KorisnikID, PomocnaDnDDatnaDat, DatumVrednost).SafeFireAndForget();
OnLoadPrometNedelja(KorisnikID, PomocnaDnDDatnaDatNedelja).SafeFireAndForget();
To handle any Exception thrown by that Task, use onException. Here's an example that prints the Exception to the Debug Console:
OnLoadPrometDanKorisnikDatum(KorisnikID, PomocnaDnDDatnaDat, DatumVrednost).SafeFireAndForget(ex => Debug.WriteLine(ex));
OnLoadPrometNedelja(KorisnikID, PomocnaDnDDatnaDatNedelja).SafeFireAndForget(ex => Debug.WriteLine(ex));

Timeout for asynchronous Task<T> with additional exception handling

In my project, I reference types and interfaces from a dynamic link library.
The very first thing I have to do when using this specific library is to create an instance of EA.Repository, which is defined within the library and serves as kind of an entry point for further usage.
The instantiation EA.Repository repository = new EA.Repository() performs some complex stuff in the background, and I find myself confronted with three possible outcomes:
Instantiation takes some time but finishes successfully in the end
An exception is thrown (either immediately or after some time)
The instantiation blocks forever (in which case I'd like to cancel and inform the user)
I was able to come up with an asynchronous approach using Task:
public static void Connect()
{
// Do the lengthy instantiation asynchronously
Task<EA.Repository> task = Task.Run(() => { return new EA.Repository(); });
bool isCompletedInTime;
try
{
// Timeout after 5.0 seconds
isCompletedInTime = task.Wait(5000);
}
catch (Exception)
{
// If the instantiation fails (in time), throw a custom exception
throw new ConnectionException();
}
if (isCompletedInTime)
{
// If the instantiation finishes in time, store the object for later
EapManager.Repository = task.Result;
}
else
{
// If the instantiation did not finish in time, throw a custom exception
throw new TimeoutException();
}
}
(I know, you can probably already spot a lot of issues here. Please be patient with me... Recommendations would be appreciated!)
This approach works so far - I can simulate both the "exception" and the "timeout" scenario and I obtain the desired behavior.
However, I have identified another edge case: Let's assume the instantiation task takes long enough that the timeout expires and then throws an exception. In this case, I sometimes end up with an AggregateException saying that the task has not been observed.
I'm struggling to find a feasible solution to this. I can't really cancel the task when the timeout expires, because the blocking instantiation obviously prevents me from using the CancellationToken approach.
The only thing I could come up with is to start observing the task asynchronously (i.e. start another task) right before throwing my custom TimeoutException:
Task observerTask = Task.Run(() => {
try { task.Wait(); }
catch (Exception) { }
});
throw new TimeoutException();
Of course, if the instantiation really blocks forever, I already had the first task never finish. With the observer task, now I even have two!
I'm quite insecure about this whole approach, so any advice would be welcome!
Thank you very much in advance!

I'm not sure if I fully understood what you're trying to achieve, but what if you do something like this -
public static void Connect()
{
Task<EA.Repository> _realWork = Task.Run(() => { return new EA.Repository(); });
Task _timeoutTask = Task.Delay(5000);
Task.WaitAny(new Task[]{_realWork, timeoutTask});
if (_timeoutTask.Completed)
{
// timed out
}
else
{
// all good, access _realWork.Result
}
}
or you can even go a bit shorter -
public static void Connect()
{
Task<EA.Repository> _realWork = Task.Run(() => { return new EA.Repository(); });
var completedTaskIndex = Task.WaitAny(new Task[]{_realWork}, 5000);
if (completedTaskIndex == -1)
{
// timed out
}
else
{
// all good, access _realWork.Result
}
}
You can also always call Task.Run with a CancellationToken that will time out, but that will raise an exception - the above solutions give you control of the behaviour without an exception being thrown (even though you can always try/catch)

Here is an extension method that you could use to explicitly observe the tasks that may fail while unobserved:
public static Task<T> AsObserved<T>(this Task<T> task)
{
task.ContinueWith(t => t.Exception);
return task;
}
Usage example:
var task = Task.Run(() => new EA.Repository()).AsObserved();

Async/await throwing unhandled exception

I'm trying to implement exception handling from a task but I just can't seem to get it right. I've found a few examples of the pattern but no matter what I try I always seem to get unhandled exceptions from within the task itself. I must be missing something, but I can't see what. Any help would be very much appreciated.
I've tried an example I found on MSDN but that doesn't work for me:
https://msdn.microsoft.com/en-us/library/dd997415(v=vs.110).aspx
And I followed the answer to this question but when I run the fix in Visual Studio it still complains about unhandled exceptions:
ContinueWith TaskContinuationOptions.OnlyOnFaulted does not seem to catch an exception thrown from a started task
This is the code that I initially wrote:
static void Main(string[] args)
{
TestAsync().ContinueWith(t =>
{
Console.WriteLine(t.Exception.ToString());
}, TaskContinuationOptions.OnlyOnFaulted);
Console.ReadKey();
}
static async Task<IEnumerable<string>> TestAsync()
{
IEnumerable<string> list = null;
try
{
list = await TestTask();
}
catch (Exception)
{
Console.WriteLine("Caught!");
}
return list;
}
static Task<IEnumerable<string>> TestTask()
{
var task = new Task<IEnumerable<string>>(() =>
{
throw new AggregateException("This is a test");
});
task.Start();
return task;
}

Just hit continue after VS breaks, you will see it gets to your ContinueWith. It is just a quirk of the debugger because it cannot find a try/catch within your code that handles the execption.
If you don't want the debugger to stop and show you a message you will need to disable "Just My Code" in the debugger options so that the try/catch that lives inside of Task gets counted as the thing that catches the exception.

Multithreaded app debug issue

I have a multithreaded .Net App developed in Mono (Xamarin) with a lot of background async-running Tasks
public Task UpdateAsync()
{
return Task.Run (() => {
.....
});
}
My issue is that one of the Task fails at some random point and crashes and closes the application without any error and no breakpoint triggers. I haven't been able to pinpoint the issue and its really hard since there alot of running async Tasks.
Is there a way to find what Method and line the issue is or even better break at that point?
EDIT:
i also tried registering UnhandledException as suggested below , but it still not handling any errors, the app just closes without any trace
AppDomain.CurrentDomain.UnhandledException += (o, e) =>{ Debugger.Break(); }
EDIT2:
i finally found the issue thanks to all the help here. Is it possible to suggest a way to prevent this (make the debugger break , not app crash) by altering the code below?
public Task StagedUpdateAsync()
{
return Task.Run (() => {
.
.
.
InvokeOnMainThread (() =>
{
// somehow here it was trying to use a null object
// and application crashed
});
});
}

First of all, I want to note that the Tasks themselves do not raise the exceptions from their inner code until they are directly being asked for a Result property or Wait* method or any other blocking methods, so the perfect place to search the exception is the resulting part of your code.
MSDN has a perfect article regarding the exception handling for the Tasks, you should go through it to select your own way to handle exception. I'll reproduce the main ideas from article here, but you suggest you to read the whole article:
try/catch block, easiest for the writing, but if you have a lot of tasks, it can be challenging to select a place for it in your code. Note that you should catch the AggregateException as a wrapper for inner exception, like this:
var task1 = Task.Run( () => { throw new CustomException("This exception is expected!"); } );
try
{
task1.Wait();
}
catch (AggregateException ae)
{
// foreach here
}
Wait for the task to complete and examine it's state:
var task1 = Task.Run( () => { throw new CustomException("This exception is expected!"); } );
while(! task1.IsCompleted) {}
if (task1.Status == TaskStatus.Faulted)
{
// foreach here
}
If your code is creating some inner tasks (either attached or not), or you are creating an array of tasks, they can also raise the exceptions, and you should examine the flatten version of the AggregateException:
try {
task1.Wait();
}
catch (AggregateException ae) {
throw ae.Flatten();
}
try {
Task.WaitAll(tasks.ToArray());
}
catch (AggregateException ae) {
throw ae.Flatten();
}
Use the tasks continuation for filtering the faulted ones (note that the exception is still an AggregateException one:
var task1 = Task.Run(() =>
{ throw new CustomException("task1 faulted.");
}).ContinueWith(t => { Console.WriteLine("{0}: {1}",
t.Exception.InnerException.GetType().Name,
t.Exception.InnerException.Message);
}, TaskContinuationOptions.OnlyOnFaulted);
If you're still missing the exception, use the UnobservedTaskException event for the TaskScheduler you are using, similar to one you're trying to handle in AppDomain (event args is an UnobservedTaskExceptionEventArgs):
TaskScheduler.Default.UnobservedTaskException += (o, e) => {
Console.WriteLine(e.Exception.ToString());
Debugger.Break();
}
// or
TaskScheduler.Current.UnobservedTaskException += (o, e) => {
Console.WriteLine(e.Exception.ToString());
Debugger.Break();
}

You could try adding this:-
AppDomain.CurrentDomain.UnhandledException += (o,e) =>{ Debugger.Break();}
And then examine e to see what the exception is, you should be able to open the threads window and switch to the thread thats causing the issue and then step back using the call stack.

For me this sounds very much like an async void issue. Read up on it here, it basically says:
In short, exceptions thrown when calling an async void method isn't handled the same way as awaiting a Task and will crash the process. Not a great experience.
Especially not a great experience since you won't be able to catch it in the debugger. Probably the problem you're experiencing right now. So I'd suggest you to go hunt your async void methods down. Now the problem is that async void methods can be obvious to spot
public async void Foo()
{
await Task.Run(() => {});
}
or well hidden behind a lambda
Action foo = async () => await Task.Run(() => {});
so it becomes a pretty tedious task to flag them down in a larger codebase. Fortunately the author of the before mentioned article provides an automized solution to search for async void signatures based on reflection. Go check it out.
If you're using Visual Studio 2015 you also might use a code analyzer based on Roslyn. There's one especially for async/await available on GitHub.
Both approaches also work well in order to avoid the problem in the future by regulary checking the codebase for async void signatures.
Good luck!

How to catch errors from worker threads in console application written in C#

I currently have a small console application that runs a number of Tasks (using Parallel.ForEach) and each one of these tasks creates sub-threads using ThreadPool.QueueUserWorkItem.
I would like the application to handle any exception thrown by these tasks/threads.
Will surrounding the Parallel.ForEach statement with try..catch work if the threads throw any errors or will they just die out?
EDIT: These sub-threads simulate users of the system. Refer to this question.

Surrounding the statement will not do the job. You can do something like this:
public static void Main(string[] args)
{
string[] files = System.IO.Directory.GetFiles(#".", "*.*");
Parallel.ForEach(files, x =>
{
try
{
MyAction(x);
}
catch(Exception ex)
{
Console.WriteLine(ex.ToString());
}
});
}
static void MyAction(string x)
{
throw new ApplicationException("Testing: " + x);
}

Don't use QUWI. I have a brief comparison of background task types on my blog (Task, BackgroundWorker, Delegate.BeginInvoke, ThreadPool.QueueUserWorkItem, and Thread).
For background tasks, Task is the clear winner. QueueUserWorkItem is very low-level by comparison.
In particular, your problem is error propogation, and Task has built-in support for this that is entirely lacking in QueueUserWorkItem. You could build it in yourself by wrapping your delegate in a try/catch, storing the exception as part of the delegate argument (or as a bound variable of a lambda expression), explicitly checking it later, and doing some technically unsupported reflection to preserve the stack trace.
But why bother? Task supports error propogation out of the box.

you can handle all exceptions with try/catch, for example:
try
{
MyParallelMethod();
}
catch(Exception e)
{
//...
}
and in your method, do something like that:
public void MyParallelMethod()
{
var data = new List<String>();
//...
Parallel.ForEach(data, d =>
{
try
{
//...
}
catch (Exception e)
{
//...
}
});
}

Will surrounding the Parallel.ForEach statement with try..catch work if the threads throw any errors or will they just die out?
No, you need to put try/catch inside the sub threads.

Error handling must be implemented in the task itself (the job each ). You need to make sure the task you are creating handles the exception.
Parallel.ForEach will not handle it for you since the exception will be raised not in the thread which is calling the Parallel.ForEach.
Alternative is to use Task<T>.