7

I dont want to catch some exception. Can I do it somehow?

Can I say something like this:

catch (Exception e BUT not CustomExceptionA)
{
}

?

abatishchev
  • 98,240
  • 88
  • 296
  • 433
silla
  • 1,257
  • 4
  • 15
  • 32

6 Answers6

21
try
{
      // Explosive code
}
catch (CustomExceptionA){ throw; }
catch (Exception ex)
{
    //classic error handling
}
Steve B
  • 36,818
  • 21
  • 101
  • 174
9
try
{
}
catch (Exception ex)
{
    if (ex is CustomExceptionA)
    {
        throw;
    }
    else
    {
        // handle
    }
}
abatishchev
  • 98,240
  • 88
  • 296
  • 433
9

Starting with C# 6, you can use an exception filter:

try
{
    // Do work
}
catch (Exception e) when (!(e is CustomExceptionA))
{
    // Catch anything but CustomExceptionA
}
Jordan Parker
  • 1,208
  • 1
  • 16
  • 25
3

You can filter it:

if (e is CustomExceptionA) throw;

And of course you can catch it and rethrow it:

try
{
}
catch (CustomExceptionA) { throw; }
catch (Exception ex) { ... }
Felix K.
  • 6,201
  • 2
  • 38
  • 71
2

First off, it's bad practice to catch Exception unless you log and re-throw it. But if you must, you need to catch your custom exception and re-throw it like so:

try
{
}
catch (CustomExceptionA custome)
{
    throw custome;
}
catch (Exception e)
{
    // Do something that hopefully re-throw's e
}
n8wrl
  • 19,439
  • 4
  • 63
  • 103
-1

After being schooled by @Servy in the comments, I thought of a solution that'll let you do [what I think] you want to do. Let's create a method IgnoreExceptionsFor() that looks like this:

public void PreventExceptionsFor(Action actionToRun())
{
    try
    {
         actionToRun();
    }
    catch
    {}
}

This can then be called like this:

try
{
     //lots of other stuff
     PreventExceptionsFor(() => MethodThatCausesTheExceptionYouWantToIgnore());
     //other stuff
}
catch(Exception e)
{
    //do whatever
}

That way, every line except for the one with PreventExceptionsFor() will throw exceptions normally, while the one inside PreventExceptionsFor() will get quietly passed over.

Phillip Schmidt
  • 8,805
  • 3
  • 43
  • 67
  • @Servy it appears to me that the OP would like certain exceptions to be ignored and others handled, with the code continuing to run after the ignored ones. Several others posted ways to throw exceptions up to a higher level, but none achieve that functionality. If the OP wanted to know how to rethrow exceptions up to a higher level, it seems he would have asked it that way. Note that code inside the `try` won't be continued after the exception is rethrown. – Phillip Schmidt Sep 06 '12 at 14:05
  • the OP asked for a way to not catch a certain type of exception. The effect of not catching it is that the exception is re-thrown until it hits another try/catch block, not that it continues execution at the point where the exception was thrown. He didn't ask how to prevent the exception from being thrown in the first place. While technically the provided solutions do catch the custom exception, the effect is that the exception appears to never have been caught because it is re-thrown. – Servy Sep 06 '12 at 14:08
  • @Servy the only logical reason anyone would want to rethrow an exception is to catch it elsewhere. If he wanted to catch it elsewhere, he wouldn't be asking how not to catch exceptions. My guess is that he has an exception which he expects to get thrown, but the exception being thrown doesn't necessarily cause any problems. Maybe something like `var a Session["whatever"]; if(a==null) a=default(A);` If Session throws a nullref or something, who cares, we still want to get the default value. My answer is the only one that allows this. – Phillip Schmidt Sep 06 '12 at 14:13
  • `the only logical reason anyone would want to rethrow an exception is to catch it elsewhere` That, or it's a fatal exception that ought to crash the app. Note that he has said nothing that would imply wanting the behavior you've asked for. If that is what he wants, then he'll need to ask for it. Additionally, your answer doesn't involve that exception not being thrown, which is what you seem to think the OP wants. You answer is basically, "explicitly catch every exception other than the custom exception that extends `Exception`". That's not a particularly practical option. – Servy Sep 06 '12 at 14:18
  • @Servy Given that the question asks "How do I catch all exceptions except a certain one?", I would say that "catch every exception other than the custom exception" actually seems like a pretty spot-on answer, no? By assuming he is dealing with a fatal exception, you're making a guess just as much as I am. So whose answer is more correct? I dunno, it depends on what the OP actually wants. My answer does give the benefit of not encouraging bad coding practice, though. Exceptions should (almost) never be rethrown. It's better to just let them bubble up to somewhere they can be handled. – Phillip Schmidt Sep 06 '12 at 14:42
  • If there are only two or three other possible execptions then sure, your approach isn't that bad. What if there are 10, or 50, or more? What if you don't know what exceptions could possibly be thrown, or if you're calling out to 3rd party code that could potentially throw different exceptions as the versions change? How is rethrowing an exception worse that letting it bubble up. There's practically no difference that I can think of between the two options. – Servy Sep 06 '12 at 14:58
  • @Servy Well what you're forgetting is that if I'm correct in my assumption of the OP's needs, he doesn't have another choice (assuming he doesn't want to change the architecture). If he has a million different exceptions to deal with and wants to ignore just one of them, he ought to change up his structure rather than work around exceptions. And logic/performance wise, you're right -- there's virtually no difference. It's just a matter of coding standard. Exceptions should be caught only when there is something that can be done about them right then and there. – Phillip Schmidt Sep 06 '12 at 15:36
  • I apply the logic of not catching exceptions that you can't handle only to exceptions that aren't re-thrown. If you are re-throwing it then you are clearly indicating that you haven't resolved the exception. – Servy Sep 06 '12 at 15:39
  • @Servy but then why rethrow it? why not just let it bubble up without having to add unnecessary code? – Phillip Schmidt Sep 06 '12 at 15:46
  • It's bubbling up in either case. In the act of re-throwing it is designed to prevent the adding of unnecessary code. I feel that a catch block with a `throw;` along with a catch block that handles every other exception has much less redundant code then a block that has a dozen different catch blocks all with the same contents. It is also riskier and less maintainable as new exceptions will need to be added over time, and it is easily possible to miss one. How do you think that having all of those catch blocks will be **less** code? – Servy Sep 06 '12 at 15:49
  • @Servy I was actually just speaking in a general sense. In this specific case, it isn't a matter of which one is "better", it's a matter of which one **works**. And, once again assuming I'm correct about the OP's direction, my answer is the only solution that **works**. I don't like having several catch blocks either, and if it were me, I'd find a way to restructure my code to not need them, but in this example, it's the one and only way to do it. – Phillip Schmidt Sep 06 '12 at 15:53
  • If your code is missing a catch block for any exception, or isn't maintained properly as the set of possible exceptions changes then your code won't work. If it is correct, then both will work equally. What about re-throwing the exception doesn't work? How is the effect of re-throwing it any different than not catching it in the first place? – Servy Sep 06 '12 at 15:56
  • @Servy when you catch an exception, whether you rethrow it or not, code is going to stop execution at the moment of the exception. If you *dont* catch it, it'll keep running. If that was his intention, there is a huge difference. – Phillip Schmidt Sep 06 '12 at 16:30
  • No, it won't. If there is an exception and you con't catch it then execution will stop, the method will return control to the calling method, which will either catch it or return control to its caller, and so on, until the application crashes or the exception is caught. Ignoring the exception doesn't make the program continue on as if it never happened, it makes the program crash. – Servy Sep 06 '12 at 16:32
  • @Servy Good point. I had my wires crossed. Ok, going to edit now. – Phillip Schmidt Sep 06 '12 at 18:52