Update from the future: TL;DR to catch expressions in async methods you have to await, Task.WaitAll, or .Result.
I created a somewhat convoluted async method that just runs other async methods. You can disregard most of it as only the line var mSpekTask... is of interest, also, I don't care about the logic, I only want to know where my exception went. My main problem is that ex.ToString() is never hit even though inside mSpecTask an exception definitly happens.
public async Task LoadAsync(IEnumerable<ProductRequest> feed, int? customerId,
IProgress<int> mSpecProgress, Action<Task> mSpecCompletionHandler)
{
var ids = feed.Select(x => x.ProductId.ToString()).Distinct().ToList();
try
{
var mSpecTask = this.LoadMSpecAsync(mSpecProgress, ids);
}
catch (Exception ex)
{
ex.ToString();
}
}
Here is the code for LoadMSpecAsync
public Task<ResultSet> LoadMSpecAsync(IProgress<int> prg, IEnumerable<string> ids)
{
return this.LoadAsync(prg, ids, Selector.M, SPMS, x => x.Order);
}
Here is the code for LoadAsync, await db.ExecuteTVP(progress, spName, ids, parameters) generates an exception.
private async Task<Dictionary<Pair, dynamic>> LoadAsync(IProgress<int> progress,
IEnumerable<string> ids, Selector s, string spName, Func<dynamic, int> k,
Func<dynamic, dynamic> f = null, object parameters = null)
{
parameters = new ExpandoObject().CopyFromSafe(parameters);
if (spName != SPMAP) ((dynamic)parameters).lang = this.languageCode;
using (var db = new SqlConnection(this.connectionString))
{
await db.OpenAsync();
var results = await db.ExecuteTVP(progress, spName, ids, parameters);
db.Close();
}
return this.data[s];
}
When an async method throws an exception, that exception is placed on the returned Task. It's not raised directly to the caller. This is by design.
So, you have to either await the Task returned from LoadMSpecAsync or have your mSpecCompletionHandler examine its Task argument for exceptions. It will show up there.
You can handle unobserved Task exceptions as follows:
TaskScheduler.UnobservedTaskException += (object sender, UnobservedTaskExceptionEventArgs eventArgs) =>
{
eventArgs.SetObserved();
((AggregateException)eventArgs.Exception).Handle(ex =>
{
//TODO: inspect type and handle exception
return true;
});
};
I'm going to add an answer to my own question because there's a useful piece of information that I found out. The intermediary method LoadMSpecAsync is swalloing the exception. For this not to happen it needs a little teak. You need to add the async keyword before the return type and the "await" keyword after "return".
I had an Exception being swallowed by myTask.Wait() (or WaitAsync), but it was a task-nesting issue. That is, when I did the myTask.Wait(), myTask had a passed-in parameter Task that ALSO called myParameterTask.Wait(). The parameter task had its own Exception-catch and no throw, so the originally thrown Exception wasn't propagating back to the calling thread.
I thought there was an issue with myTask.Wait() throwing Exceptions, but it wasn't.
Related
According to the Microsoft Docs:
There are two common use cases for local functions: public iterator methods and public async methods. Both types of methods generate code that reports errors later than programmers might expect.
...
The technique can be employed with async methods to ensure that exceptions arising from argument validation are thrown before the asynchronous work begins:
public Task<string> PerformLongRunningWork(string address, int index, string name)
{
if (string.IsNullOrWhiteSpace(address))
throw new ArgumentException(message: "An address is required", paramName: nameof(address));
if (index < 0)
throw new ArgumentOutOfRangeException(paramName: nameof(index), message: "The index must be non-negative");
if (string.IsNullOrWhiteSpace(name))
throw new ArgumentException(message: "You must supply a name", paramName: nameof(name));
return longRunningWorkImplementation();
async Task<string> longRunningWorkImplementation()
{
var interimResult = await FirstWork(address);
var secondResult = await SecondStep(index, name);
return $"The results are {interimResult} and {secondResult}. Enjoy.";
}
}
I don't really understand this example. If we just get rid of the local function and extract its contents to the outer scope and put them right after the validation, won't we achieve the same result? What does the local function actually give in this case?
If it actually doesn't improve anything, can you come up with a better example?
There's a difference between:
Call PerformLongRunningWork and it throws an exception.
Call PerformLongRunningWork and it successfully executes, and gives you back a Task<string> which contains an exception.
That is:
Task<string> task;
try
{
task = PerformLongRunningOperation();
}
catch (Exception e)
{
// PerformLongRunningOperation itself threw
}
bool containsException = task.IsFaulted;
try
{
string result = await task;
}
catch (Exception e)
{
// The Task<string> returned from PerformLongRunningWork contained an exception
}
If you throw an exception from an async Task method, that exception is wrapped up inside the Task which is returned.
Therefore, your example with a non-async method which delegates to an async local function will throw those ArgumentException directly when it's called, and not return them wrapped up in the Task<string> it returns.
If you rewrote the example to remove the local function and instead make PerformLongRunningWork async, then those ArgumentExceptions would be wrapped up inside the Task<string> returned.
Which one you want to do is a matter of debate.
One of the benefits: I don't have to pass local variables and parameters as parameters to the other method since they are already captured.
Another use case that I benefit from frequently is working with TaskCompletionSource<T>. An example of that:
public Task<T> DoSomeWorkAsync()
{
TaskCompletionSource<T> completionSource = new TaskCompletionSource<T>();
SomeBackgroundWorker worker = new SomeBackgroundWorker();
worker.OnWorkComplete += workComplete;
worker.DoSomeWorkInABackgroundThread();
return completionSource.Task;
void workComplete(T workResult)
{
worker.OnWorkComplete -= workComplete;
completionSource.SetResult(workResult);
}
}
I'm designing some code right now where I'm throwing an exception if a string parameter is null or empty and the exception is thrown as it should be, but it isn't getting caught when I'm UnitTesting.
Here's the client I'm using.
public class PipeClient : IPipeClient
{
public async void Send(string host, string pipeName, Message msg)
{
if (string.IsNullOrEmpty(msg.PreparedMessage))
throw new ArgumentException("MESSAGE_NOT_FOUND");
if (string.IsNullOrEmpty(host) || string.IsNullOrEmpty(pipeName))
throw new ArgumentNullException();
if (!host.TryParseHost())
throw new ArgumentException("INVALID_HOST_NAME");
using (var pipeClient = new NamedPipeClientStream(host, pipeName, PipeDirection.Out))
{
pipeClient.Connect(200);
using (var writer = new StreamWriter(pipeClient))
{
await Task.Run(() => writer.WriteLine(msg.PreparedMessage));
writer.Flush();
}
}
}
}
And here's the UnitTest
[TestMethod]
public void Send_FailsOnWrongHostName()
{
var name = "FailWithHostname";
var msg = new Message(MyStates.Register, "UnitTest", "Test");
try
{
var client = new PipeClient();
client.Send("lol", name, msg);
}
catch (Exception e)
{
Assert.IsTrue(e is ArgumentException);
}
}
So when I run that test it should as far as I know throw the exception when I call the the Send method (which is does) and then get caught in the catch clause because I'm not catching it inside the PipeClient. Yet it doesn't, it just exits with a failed test.
If you need any more information just let me know, thanks in advance.
there's a few things I want to raise in this answer. I'm not sure of your experience level so please don't think I'm being condescending at any point.
Firstly a brief note on async methods and Tasks.
Async void should be avoided unless in an async event handler. Async methods should return Task or Task otherwise there is nothing for the calling method to keep hold of to know when the method is done and to report back whether the method threw an exception. Async void is essentially fire and forget, there is no one left to observe the exceptions.
"In observed Tasks no one can you scream" -Me ,2018
Exceptions thrown in async methods are nicely unwrapped and thrown
when the async method is awaited, with the call stack all preserved
and reasonably sensible. If you don't await the result eventually at
some point in the future you will get an UnobservedTaskException
that, if you haven't configured a global handler for, will bring down
your application. If you get the result of an async method
synchronously using .Wait() or .Result or via
.GetAwaiter().GetResult() (all 3 you should try and avoid but the 3rd
option is best if you have to I have been informed), then you will
get the original exception wrapped in an AggregateException.
Now if none of this is making much sense to you, I would recommend doing some reading up Tasks and async/await.
Now onto your Test.
Your method is async void so there is nothing for the calling method to have returned to it to represent the work or to let it know that the method has thrown an exception. So it carries on, the test finishes and then everything completes with no exceptions because the UnobservedTaskException can be thrown at anypoint in the future (I think it is related to when the garbage collector tidies up the faulted Task and then it throws and because the garbage collector is non-deterministic we can't say when that will happen)
So what if you made your async method return a Task??? Well that's still not quite right. You are now returning a Task that will be in a faulted state because of the exception, however because you never await it, the exception is never 'unwrapped' and actually thrown and so you're test happily continues.
What you need to do is make your Test async and return a Task and make the method you're testing async Task not async void and await that method in your test.
Like this
[TestMethod]
public async Task Send_FailsOnWrongHostName()
{
var name = "FailWithHostname";
var msg = new Message(MyStates.Register, "UnitTest", "Test");
try
{
var client = new PipeClient();
await client.Send("lol", name, msg);
}
catch (Exception e)
{
Assert.IsTrue(e is ArgumentException);
}
}
public class PipeClient : IPipeClient
{
public async Task Send(string host, string pipeName, Message msg)
{
if (string.IsNullOrEmpty(msg.PreparedMessage))
throw new ArgumentException("MESSAGE_NOT_FOUND");
if (string.IsNullOrEmpty(host) || string.IsNullOrEmpty(pipeName))
throw new ArgumentNullException();
if (!host.TryParseHost())
throw new ArgumentException("INVALID_HOST_NAME");
using (var pipeClient = new NamedPipeClientStream(host, pipeName, PipeDirection.Out))
{
pipeClient.Connect(200);
using (var writer = new StreamWriter(pipeClient))
{
await Task.Run(() => writer.WriteLine(msg.PreparedMessage));
writer.Flush();
}
}
}
}
The method RelatoriosEstaticos.AbrirDataAtual that is within the Task below is returning an exception already handled in the method itself, the problem is that the Task continues execution of the next line var links = ListArquivos.ListaLinksDownlaod(driver); which depends on the method AbrirDataAtual() to be executed, it also throws an exception. I have tried to treat within the method, put the task inside a Try / catch, but nothing works, there is always the exception in the method ListaLinksDownlaod and should not even get there.
How can I stop the execution of the task, such as when we send a CancellationToken, but this time, when an exception occurs.
private async Task<List<IWebElement>> Acessar(IWebDriver driver, string data, CancellationToken ct)
{
return await Task.Run(() =>
{
ct.ThrowIfCancellationRequested();
LoginNgin.Login(config.User, config.Password, driver);
RelatoriosEstaticos.AbrirRelatoriosEstaticos(driver);
RelatoriosEstaticos.AbrirDataAtual(driver, data);
var links = ListArquivos.ListaLinksDownlaod(driver);
MethodInvoker action = delegate { pgbStatus.Maximum = links.Count(); };
pgbStatus.BeginInvoke(action);
return links;
});
}
It's not possible to tell for sure without seeing actual implementation of AbrirDataAtual, but it definitely looks like this method is handling exception that should not be handled there.
Generally, method should handle exception only if it can handle it properly (by properly I mean it can recover application to the state where program can safely continue, inform user about the error, etc.), otherwise it should not handle it at all and let the exception propagate to the caller(s) of the method.
Based on description of your problem, AbrirDataAtual doesn't (and can't) handle the exception properly, so you should not catch the exception there (or if excetion must be caught there, you should re-throw it). All following methods (including ListArquivos.ListaLinksDownlaod) will be skipped up to the point, where exception is handled. Problem solved!
The following example shows how to handle the exception directly in the task (after you remove exception handling in AbrirDataAtual). But it's likely that it's still not the best place for such exception handler, but again, finding such place would require complete source code so take it just as an example to clarify what I'm talking about:
private async Task<List<IWebElement>> Acessar(IWebDriver driver, string data, CancellationToken ct)
{
return await Task.Run(() =>
{
ct.ThrowIfCancellationRequested();
LoginNgin.Login(config.User, config.Password, driver);
RelatoriosEstaticos.AbrirRelatoriosEstaticos(driver);
try
{
RelatoriosEstaticos.AbrirDataAtual(driver, data);
var links = ListArquivos.ListaLinksDownlaod(driver);
MethodInvoker action = delegate { pgbStatus.Maximum = links.Count(); };
pgbStatus.BeginInvoke(action);
return links;
}
catch (Exception)//Use more specific exception type if possible
{
//Do all neccesary to properly handle the exception
}
});
}
If you still believe that AbrirDataAtual method is the right place to handle the exception, an alternative approach is to modify AbrirDataAtual to return boolean flag indicating success/failure of it's operation, e.g.:
bool AbrirDataAtual(IWebDriver driver, string data)
{
try
{
//Do all the neccessary stuff
...
//Indicate that AbrirDataAtual succeeded
return true;
}
catch(Exception)
{
//Handle exception properly
...
//Indicate that AbrirDataAtual failed
return false;
}
}
private async Task<List<IWebElement>> Acessar(IWebDriver driver, string data, CancellationToken ct)
{
return await Task.Run(() =>
{
ct.ThrowIfCancellationRequested();
LoginNgin.Login(config.User, config.Password, driver);
RelatoriosEstaticos.AbrirRelatoriosEstaticos(driver);
if (RelatoriosEstaticos.AbrirDataAtual(driver, data))
{
//Continue execution
var links = ListArquivos.ListaLinksDownlaod(driver);
MethodInvoker action = delegate { pgbStatus.Maximum = links.Count(); };
pgbStatus.BeginInvoke(action);
return links;
}
else
{
//AbrirDataAtual failed
return null;
//or throw exception if appropriate
throw new Exception();
}
});
}
I have a strange problem combining the async/await to make it work:
I created a small procedure, which should handle basically the try/catch of every action:
internal static void HandledAction(Action action, Info infoBar)
{
try
{
action();
}
catch (Exception ex)
{
infoBar.SetError("An Exception occured: " + ex.Message);
WriteLog(ex.StackTrace);
}
Nohing to fancy, but it's worth since changing error-handling is very easy made.
But what happens, if I'd like to get Data async in the Lambda? Lets take this simple example:
private void mnuImportData_Click(object sender, RoutedEventArgs e)
{
ActionHelper.HandledAction(async () =>
{
throw new NotImplementedException("Ups");
}, infoMain);
}
Sure, the HandledAction gets called, passes, since it gets the pointer back, and the exception gets thrown, of course not handled.
I imagine I have to create a AsyncHandledAction, and set the action async, but is there a easier way to solve this problem?
I guess many people use a central exception-handling, and there are far better solutions for this?
Thanks in advance
Matthias
Edit: I created an example, which should shpw netter I need: I basically dont want the whole Action I pass being awaitable, but one call in the Lambda is:
ActionHelper.HandledActionAsync(() =>
{
//elided
CheckFileResult rslt = await excelImport.CheckFilesAsync(tmpPath);
//elided
}, infoMain);
Of course, by doing so, I get the error:
Error 3 The 'await' operator can only be used within an async lambda expression. Consider marking this lambda expression with the 'async' modifier.
The reason is: Action instead of Func. Since yours:
async () =>
{
throw new NotImplementedException("Ups");
}
in fact is:
async void Method() { }
when Func<Task> is:
async Task Method() { }
Async void will capture SynchronizationContext.Current and when exception is thrown it will be posted to SynchronizationContext by SynchronizationContext.Post() - (in windows runtime you can catch these types of exception). In case of ASP.NET/Console application SynchronizationContext.Current returns null which means that exception would be propagated to Thread Pool and I'm not sure but I think it is not possible to catch it. However when there is returned Task by asynchronous method exception could be marshaled to the caller through this returned Task. It is also worth mention that async lambda expresions will always prefer methods with Func<Task> over Action. General rule is: never use async void (async Action) unless it is "top-level method" (in example event handler).
You need an async version of HandleAction
internal static async Task HandledAction(Func<Task> action, Info infoBar)
{
try
{
await action();
}
catch (Exception ex)
{
infoBar.SetError("An Exception occured: " + ex.Message);
WriteLog(ex.StackTrace);
}
}
of course you should call the method with await
private async void mnuImportData_Click(object sender, RoutedEventArgs e)
{
await ActionHelper.HandledAction(async () =>
{
throw new NotImplementedException("Ups");
}, infoMain);
}
When awaiting a faulted task (one that has an exception set), await will rethrow the stored exception. If the stored exception is an AggregateException it will rethrow the first and discard the rest.
How can we use await and at the same time throw the original AggregateException so that we do not accidentally lose error information?
Note, that it is of course possible to think of hacky solutions for this (e.g. try-catch around the await, then call Task.Wait). I really wish to find a clean solution. What is the best-practice here?
I thought of using a custom awaiter but the built-in TaskAwaiter contains lots of magic that I'm not sure how to fully reproduce. It calls internal APIs on TPL types. I also do not want to reproduce all of that.
Here is a short repro if you want to play with it:
static void Main()
{
Run().Wait();
}
static async Task Run()
{
Task[] tasks = new[] { CreateTask("ex1"), CreateTask("ex2") };
await Task.WhenAll(tasks);
}
static Task CreateTask(string message)
{
return Task.Factory.StartNew(() => { throw new Exception(message); });
}
Only one of the two exceptions is thrown in Run.
Note, that other questions on Stack Overflow do not address this specific problem. Please be careful when suggesting duplicates.
I disagree with the implication in your question title that await's behavior is undesired. It makes sense in the vast majority of scenarios. In a WhenAll situation, how often do you really need to know all of the error details, as opposed to just one?
The main difficulty with AggregateException is the exception handling, i.e., you lose the ability to catch a particular type.
That said, you can get the behavior you want with an extension method:
public static async Task WithAggregateException(this Task source)
{
try
{
await source.ConfigureAwait(false);
}
catch
{
// source.Exception may be null if the task was canceled.
if (source.Exception == null)
throw;
// EDI preserves the original exception's stack trace, if any.
ExceptionDispatchInfo.Capture(source.Exception).Throw();
}
}
I know I'm late but i found this neat little trick which does what you want. Since the full set of exceptions are available with on awaited Task, calling this Task's Wait or a .Result will throw an aggregate exception.
static void Main(string[] args)
{
var task = Run();
task.Wait();
}
public static async Task Run()
{
Task[] tasks = new[] { CreateTask("ex1"), CreateTask("ex2") };
var compositeTask = Task.WhenAll(tasks);
try
{
await compositeTask.ContinueWith((antecedant) => { }, TaskContinuationOptions.ExecuteSynchronously);
compositeTask.Wait();
}
catch (AggregateException aex)
{
foreach (var ex in aex.InnerExceptions)
{
Console.WriteLine(ex.Message);
}
}
}
static Task CreateTask(string message)
{
return Task.Factory.StartNew(() => { throw new Exception(message); });
}
Here is a shorter implementation of Stephen Cleary's WithAggregateException extension method:
public static async Task WithAggregateException(this Task source)
{
try { await source.ConfigureAwait(false); }
catch when (source.IsCanceled) { throw; }
catch { source.Wait(); }
}
public static async Task<T> WithAggregateException<T>(this Task<T> source)
{
try { return await source.ConfigureAwait(false); }
catch when (source.IsCanceled) { throw; }
catch { return source.Result; }
}
This approach is based on a suggestion by Stephen Toub in this API proposal in GitHub.
Update: I added a special handling of the cancellation case, to prevent the awkwardness of propagating an AggregateException that contains an OperationCanceledException. Now the OperationCanceledException is propagated directly, and the Task.IsCanceled status is preserved. Kudos to #noseratio for pointing out this flaw in the comments of this answer. Of course now this implementation is not much shorter than Stephen Cleary's approach!
Exception Handling (Task Parallel Library)
I could say more but it would just be padding. Play with it, it does work as they say. You just have to be careful.
maybe you want this
God (Jon Skeet) explains await exception handling
(personally i shy away from await, but thats just my preference)
in response to comments (too long for a comment reply)
Then use threads as your starting point for an analogous argument as the best practises there will be the source of ones for here.
Exceptions happily get swallowed unless you implement code to pass them out (for instance the async pattern that the await is preumably wrapping ... you add them to an event args object when you raise an event). When you have a scenario where you fire up an arbitrary number of threads and execute on them you have no control over order or the point at which you terminate each thread. Moreover you would never use this pattern if an error on one was relevant to another. Therefor you are strongly implying that execution of the rest is completley independent - IE you are strongly implying that exceptions on these threads have already been handled as exceptions. If you want to do something beyond handling exceptions in these threads in the threads they occur in (which is bizzarre) you should add them to a locking collection that is passed in by reference - you are no longer considering exceptions as exceptions but as a piece of information - use a concurrent bag, wrap the exception in the info you need to identify the context it came from - which would of been passed into it.
Don't conflate your use cases.
I don't want to give up the practice to only catch the exceptions I expect. This leads me to the following extension method:
public static async Task NoSwallow<TException>(this Task task) where TException : Exception {
try {
await task;
} catch (TException) {
var unexpectedEx = task.Exception
.Flatten()
.InnerExceptions
.FirstOrDefault(ex => !(ex is TException));
if (unexpectedEx != null) {
throw new NotImplementedException(null, unexpectedEx);
} else {
throw task.Exception;
}
}
}
The consuming code could go like this:
try {
await Task.WhenAll(tasks).NoSwallow<MyException>();
catch (AggregateException ex) {
HandleExceptions(ex);
}
A bone-headed exception will have the same effect as in synchronous world, even in case it is thrown concurrently with a MyException by chance. The wrapping with NotImplementedException helps to not loose the original stack trace.
Extension that wraps original aggregation exception and doesn't change return type, so it can still be used with Task<T>
public static Task<T> UnswallowExceptions<T>(this Task<T> t)
=> t.ContinueWith(t => t.IsFaulted ? throw new AggregateException("whatever", t.Exception) : t.Result);
Example:
Task<T[]> RunTasks(Task<T>[] tasks) =>
Task.WhenAll(CreateSometasks()).UnswallowExceptions();
try
{ var result = await CreateTasks(); }
catch(AggregateException ex) { } //ex is original aggregation exception here
NOTE This method will throw if task was canceled, use another approach if cancelling is important for you