ReSharper was giving me a CoVariantConversion warning so I decided to google this and see how to fix it. I came accross this snippet of code:
// ReSharper disable CoVariantArrayConversion
try
{
Task.WaitAll(taskList.ToArray());
}
catch (AggregateException ex)
{
ex.Handle(e => true);
}
// ReSharper restore CoVariantArrayConversion
This part is confusing me:
ex.Handle(e => true);
What does it do? I would think that it does nothing.
You are correct: the line can be removed and have the same effect (causing all the exceptions to be considered "handled") as if the line was there.
The only time it would be useful is if the lambda could return false for some exceptions (which it doesn't in this case).
This say, that the Exception is handled, nothing else.
Here is a sample that Shows how the Handle method could be used:
Task task = Task.Factory.StartNew(() =>
{
throw new UnauthorizedAccessException();
});
try
{
task.Wait();
}
catch (AggregateException ex)
{
ex.Handle(x =>
{
if (x is UnauthorizedAccessException)
{
// Handle this exception...
return true;
}
// Other exceptions will not be handled here.
return false;
});
}
The sample comes from this article: Asynchronous Programming - Exception Handling
Related
Does C# support compiling filters? How do filters even work or what do they do?
Like reflector decompiles a filter as
try
{
}
catch(Exception e) when (?)
{
}
Since C# 6 you can now do this.
try { … }
catch (MyException e) when (myfilter(e))
{
…
}
This is different from using an if statement from within the catch block, using exception filters will not unwind the stack.
C# did not support exception filters like VB does until C# 6. As for how they work, see Eric Lippert's "Finally" Does Not Mean "Immediately"
Starting in C# 6, exception filters are supported, as the C# FAQ demonstrates:
try { … }
catch (MyException e) when (myfilter(e))
{
…
}
If the parenthesized expression after ‘if’ [now when] evaluates to true, the catch block is run, otherwise the exception keeps going.
Exception filters are preferable to catching and rethrowing because they leave the stack unharmed. If the exception later causes the stack to be dumped, you can see where it originally came from, rather than just the last place it was rethrown.
It is also a common and accepted form of “abuse” to use exception filters for side effects; e.g. logging. They can inspect an exception “flying by” without intercepting its course. In those cases, the filter will often be a call to a false-returning helper function which executes the side effects:
private static bool Log(Exception e) { /* log it */ ; return false; }
…
try { … }
catch (Exception e) when (Log(e)) {}
Thanks to Mafii for the link to the C# 6 documentation.
Exception filters support in C# is introduced in C# 6 (Visual Studio "Dev14"):
try
{
throw new ApplicationException("1");
}
catch (ApplicationException ex) when (ex.Message == "2")
{
// this one won't execute.
}
catch (ApplicationException ex) when (ex.Message == "1")
{
// this one will execute
}
While catching exceptions, if you want to handle the exceptions differently then you can use Exception Filter
-- After C# 6.0
-- After VB 7.1 Using WHEN
1) C# Sample After C# 6.0
try
{
throw new CustomException { Severity = 100 };
}
catch (CustomException ex) when (ex.Severity > 50)
{
Console.WriteLine("*BING BING* WARNING *BING BING*");
}
catch (CustomException ex)
{
Console.WriteLine("Whooops!");
}
Note : Keep in mind that the order matters
2) C# Sample Before C# 6.0
try
{
throw new CustomException { Severity = 100 };
}
catch (CustomException ex)
{
if (ex.Severity > 50)
{
Console.WriteLine("*BING BING* WARNING *BING BING*");
}
else
{
Console.WriteLine("Whooops!");
}
}
Since this piece of code is equivalent to the previous one. means, they are equivalent, right? --- "But No they are not equivalent"
NOTE : exception filters don’t unwind the stack
Read it more from Here
I have a basic ReactiveCommand. No async wizardry, just plain old ReactiveCommand.Create(). I Subscribe() with the overload that takes an exception handler, but never hit the breakpoint in said exception handler (I did not expect this). I subscribe to ThrownErrors, never hit the breakpoint in that exception handler either (I sort of expected this).
Here's the example code:
var myCommand = ReactiveCommand.Create();
// this does not seem to work
myCommand.Subscribe(
_ => { throw new Exception("oops"); },
ex => {
Console.WriteLine(ex.Mesage);
Debugger.Break();
});
//this does not seem to work either
myCommand.ThrownExceptions.Subscribe(
ex => {
Console.WriteLine(ex.Mesage);
Debugger.Break();
});
I did my homework and checked the questions and answers in the topic.
ReactiveUI exception handling
How to catch exception from ReactiveCommand?
I have checked the mail list as well, and found this:
https://groups.google.com/forum/#!topic/reactivexaml/Dkc-cSesKPY
So I decided to change this to some async solution:
var myCommand = ReactiveCommand.CreateAsyncObservable(_ => this.Throw());
myCommand.Subscribe(
_ => { Console.WriteLine("How did we get here?"); },
// this is not expected to work
ex => {
Console.WriteLine(ex.Message);
Debugger.Break();
});
// however, I sort of expect this to work
myCommand.ThrownExceptions.Subscribe(
ex => {
Console.WriteLine(ex.Message);
Debugger.Break();
});
[...]
private IObservable<object> Throw()
{
Debugger.Break();
throw new Exception("oops");
}
And yet, I never hit any of my breakpoints, except the one in the Throw() method. :(
What am I doing wrong? How am I supposed to catch exceptions here?
Edit:
I do, however, hit the exception handler breakpoint when I throw the exception from within the observable, like this
private IObservable<object> Throw()
{
Debugger.Break();
return Task.Factory.StartNew(() =>
{
throw new Exception("oops");
return new object();
}).ToObservable();
}
Question modified to: "am I capable of handling an exception from within the method and not the observable?"
This is a bug in the current release of ReactiveUI - the exception thrown while creating the 'execute' observable is swallowed and the internal state of the ReactiveCommand is left in a broken state. This has been fixed in the next release.
See this github issue for details.
Comparing the old way versus the new way of error handling, by using Exception filters, what is exactly the advantage for me of using filters and when should I use it? is there an scenario where I can get a good advantage of this new feature?
I have read about the unwinding stack but still I don't get the scenario where we can not handle that under the old way. Explain like I'm 5 please.
try
{
Foo.DoSomethingThatMightFail(null);
}
catch (MyException ex) when (ex.Code == 42)
{
Console.WriteLine("Error 42 occurred");
}
vs
try
{
Foo.DoSomethingThatMightFail(null);
}
catch (MyException ex)
{
if (ex.Code == 42)
Console.WriteLine("Error 42 occurred");
else
throw;
}
I know there is other version of this question, the problem is, that the question mention benefits that I cant actually find, for instance.
Exception filters are preferable to catching and rethrowing because
they leave the stack unharmed. If the exception later causes the stack
to be dumped, you can see where it originally came from, rather than
just the last place it was rethrown.
after doing some testing, I did not see the difference between both, I still see the exception from the place it was rethrown. So, or the information is not confirmed, I don't understand the Exception filters( that is why I am asking), or I am doing it wrong (also please correct me if I am wrong).
class specialException : Exception
{
public DateTime sentDateTime { get; } = DateTime.Now;
public int code { get; } = 0;
public string emailsToAlert { get; } = "email#domain.com";
}
then:
try
{
throw new specialException();
//throw new Exception("Weird exception");
//int a = Int32.Parse("fail");
}
catch (specialException e) when(e.code == 0)
{
WriteLine("E.code 0");
throw;
//throw e;
}
catch (FormatException e)
{
if (cond1)
{
WriteLine("cond1 " + e.GetBaseException().Message+" - "+e.StackTrace);
throw;
}
throw;
}
catch (Exception e) //when (cond2)
{
Console.WriteLine("cond2! " + e.Message);
throw;
}
I don't understand Paulo's answer. He may be correct or he may not be.
I definitely disagree with Alexander's answer. It is not just syntactic sugar. Pure syntactic sugar means it's solely an easier way of writing something, and that execution will be unchanged.
However, that's not the case in this situation. As Thomas Levesque points out in his blog, exception filters do not unwind the stack. So when debugging the program, if you have an exception thrown in your try block, with exception filters you'll be able to see what the state of the values are in the try block. If you weren't using exception filters, your code would enter the catch block and you would lose information about the state of the variables in the try block.
Note that I'm not talking about the stacktrace (it's a different but related concept to the stack). The stacktrace would be unchanged unless you explicitly did rethrow the exception as in throw exception; in a catch block where exception is the caught exception.
So while in some cases you can think of it as something that may or may not make your code cleaner (depending on your opinion of the syntax), it does change the behavior.
Exception filters have been added to C# because they were in Visual Basic and the "Roslyn" team found them useful when developing "Roslyn".
Beware that the filter runs in the context of the throw and not in the context of the catch.
Anyhow, one use might be something like this:
try
{
//...
}
catch (SqlException ex) when (ex.Number == 2)
{
// ...
}
catch (SqlException ex)
{
// ...
}
Edited:
One might think this is just syntactic sugar over this:
try
{
//...
}
catch (SqlException ex) when (ex.Number == 2)
{
// ...
}
catch (SqlException ex)
{
if (ex.Number == 2)
{
// ...
}
else
{
// ...
}
}
But if we change the code for this:
try
{
//...
}
catch (SqlException ex) when (ex.Number == 2)
{
// ...
}
It will be more like this:
try
{
//...
}
catch (SqlException ex) when (ex.Number == 2)
{
// ...
}
catch (SqlException ex)
{
if (ex.Number == 2)
{
// ...
}
else
{
throw
}
}
But there's one fundamental difference. The exception is not caught and rethrown if ex.Number is not 2. It's just not caught if ex.Number is not 2.
UPD: As pointed out in the answer by Paulo Morgado, the feature has been in CLR for quite some time and C# 6.0 only added syntax support for it. My understanding of it, however, remains as a syntactic sugar, e.g. the syntax that allows me to filter exceptions in a nicer way than it used to be, irrespective of how the previous "straightforward" method works under the hood.
=====
In my understanding, this is a syntactic sugar that allows you to more clearly define the block there your exception is going to be handled.
Consider the following code:
try
{
try
{
throw new ArgumentException() { Source = "One" };
throw new ArgumentException() { Source = "Two" };
throw new ArgumentException() { Source = "Three" };
}
catch (ArgumentException ex) when (ex.Source.StartsWith("One")) // local
{
Console.WriteLine("This error is handled locally");
}
catch (ArgumentException ex) when (ex.Source.StartsWith("Two")) // separate
{
Console.WriteLine("This error is handled locally");
}
}
catch (ArgumentException ex) // global all-catcher
{
Console.WriteLine("This error is handled globally");
}
Here you can clearly see that first and second exception are handled in the respective blocks that are separated using when safeguard, whereas the one global catch-all block will catch only the third exception. The syntax is clearer that catching all the exceptions in every block, something like:
catch (ArgumentException ex) // local
{
if (ex.Source.StartsWith("One"))
{
Console.WriteLine("This error is handled locally");
}
else
{
throw;
}
}
I have an anonymous TPL task with the following structure:
Task.Factory.StartNew(() =>
{
try
{
DoStuff();
}
catch (OperationCanceledException ex)
{
// process cancellation
}
catch (Exception ex)
{
// process (log) all exceptions
}
finally
{
// tie up various loose ends
}
},
myCancellationToken, // cancellation token
TaskCreationOptions.LongRunning, // always create a new thread
TaskScheduler.Default // default task scheduler
);
Inside of the DoStuff() function, I'm using Spring.NET Social extension for Dropbox to upload a large file to Dropbox. For some reason that I don't yet understand, an exception is being generating during the file upload (via the UploadFileAsync() method call):
(System.Net.Sockets.SocketException (0x80004005): An established connection was aborted by the software in your host machine).
I'm still working out why this exception is happening, but that's not the part that concerns me a present. The bigger problem is that the exception is ultimately wrapped by
System.Reflection.TargetInvocationException and for some strange reason, my try/catch block (in my original code snippet) isn't catching it.
Since I cannot catch the exception, it ultimately crashes the app.
Although I didn't think it should be necessary, I even tried adding an explicit catch block for TargetInvocationException, but again it never fires.
So my question is - how I do I catch this exception, and why isn't it being caught by the constructs shown in my code above?
UPDATE:
This problem appears to have nothing to do with the TPL after all. I modified the call to remove the call to StartNew() so that the code executes synchronously, and I still cannot catch this exception.
I used this code to verify that the TargetInvocationException can be caught:
[Test]
public void TaskExceptionTest()
{
var task = Task.Factory.StartNew(
() =>
{
try
{
throw new TargetInvocationException(null);
}
catch (Exception e)
{
Console.WriteLine("Caught one (inside):" + e.GetType().Name);
}
});
try
{
task.Wait();
}
catch (AggregateException ae)
{
// Assume we know what's going on with this particular exception.
// Rethrow anything else. AggregateException.Handle provides
// another way to express this. See later example.
foreach (var e in ae.InnerExceptions)
{
if (e is TargetInvocationException)
{
Console.WriteLine("After:" + e.GetType().Name);
}
else
{
throw;
}
}
}
}
You can read here about exception handling and tasks.
I have code that attempts a type conversion. If it fails, I want to try something else, and if that also fails, then rethrow the original exception attempted by the first conversion. The problem is that the only way I know of to rethrow is to have 'throw;' sitting at the end of the catch block. What happens when I only want the rethrow to happen from within another catch block?
try
{
valueFromData = Convert.ChangeType(valueFromData, pi.PropertyType);
}
catch(InvalidCastException e)
{
Debug.WriteLine(String.Concat("Info - Direct conversion failed. Attempting to convert using String as an intermidiate type."));
try { valueFromData = Convert.ChangeType(valueFromData.ToString(), pi.PropertyType); }
catch { throw e; }
}
As you can see above, I have to use 'throw e;', which resets the call stack.
Only workaround I've though of so far is (imo) gross:
bool handled = true;
...
catch { handled = false; }
if( !handled ) throw;
There is no way to rethrow an exception from an outer catch block inside an inner catch block. The best way to achieve this pattern is to note whether or not the inner operation succeeded
catch (InvalidCastException e) {
bool threw = false;
try {
...
} catch {
threw = true;
}
if (threw) {
throw;
}
}
If you are intending to make multiple attempts at conversion then it certainly makes sense to use non-throwing operations where applicable so that you sidestep the problem entirely.
Supposing that's not possible for the sake of argument, the next step is to question the throw e; approach. In the example code you give, IMHO there is no problem at all if your throw resets the call stack. Once someone gets to the source code for this method (which the modified call stack would still point to), I think it's pretty obvious what's going on. So while resetting the call stack is always a questionable decision, in this particular case it should be allowed to happen because there would be no tangible drawback.
Finally, the workaround you mention is interesting as well as gross (agree on that!).
I tried the following and it seems to achieve your goal, when the 2nd exception occurs (in this case, the ArgumentException) it throws the first exception (InvalidCastException)
[TestMethod]
[ExpectedException(typeof(InvalidCastException))]
public void ReThrowException() {
var ret = false;
try {
ret = F1(1);
}
catch (InvalidCastException ex) {
try {
ret = F1(2);
}
catch (Exception e) {
Debug.WriteLine(e.Message);
throw ex;
}
}
}
private bool F1(int i) {
if (i == 1) {
throw new InvalidCastException();
} else {
throw new ArgumentException();
}
return false;
}
Hope this helps,
Alan.