Proposal: catch multi exceptions with parameter list

[lachbaer]

Instead of

catch (Exception ex) when (ex is CommunicationException || ex is SystemException) {
    //handle it
}

(what already is an easy compared to C# 5) it would be much lighter to write

catch (CommunicationException cex, SystemException sex) {
    // both, cex and sex are set to either the exception or null if not appropriate
}

There are times when I want to catch certain exceptions that I am particularly not further interested in. The code in the catch block only exists for common error handling.

[alrz]

@lachbaer Either cex or sex is not definitly assigned once you reach catch block. I believe this belongs to intersection types and "the most specific common type" proposal. See also #118 and dotnet/roslyn#6789

[dcmeglio]

Your example still requires something like:

catch (CommunicationException cex, SystemException sex) {
    if (cex != null) { 
        //do this
    }
   else if (sex != null) {
       // do that
    }
}

So how is that any more concise than

catch (CommunicationException cex) {
    // do this
}
catch (SystemException sex) {
    // do that
}

The only time yours is shorter is if you don't care which exception occurred which I would think is rare.

By the way, I should add, C#7 already allows:

catch (Exception ex) when (ex is CommunicationException cex || ex is SystemException sex) {
    //handle it
}

[lachbaer]

@dman2306

The only time yours is shorter is if you don't care which exception occurred which I would think is rare.

In case I don't care about the details of the exception and just want to log it somehow.

There is another discussion #220. Meanwhile I really wonder if I am so misled about exceptions?! 😞

As nearly every method, every constructor, etc. may throw exceptions, do really wrap every single call in a try-catch and catch every possible exception...?!?!?!?!?!?! 😕

[dcmeglio]

I would argue your goal should be to prevent exceptions, not to handle them. Meaning, many methods throw ArgumentExceptions. Well if you follow the rules of what the method accepts, while the method can throw an exception, it won't. Granted some are things we can't control like network issues or file access issues, but no, I wouldn't think every line of code should be wrapped in a try/catch. The goal should be to avoid exceptions and handle exceptions only when they are unavoidable.

By the way, from a logging perspective, I would still say "A Communication error occurred" or "A System error occurred" vs. "Either a communication or system error occurred" that the former example is much more useful.

[MgSam]

Your example is so true. CommunicationExceptions often do lead to sex exceptions.

Sorry- couldn't resist. :)

[lachbaer]

@MgSam 😆
Lucky you! In my example in case of a CommunicationException sex will be null...

[jnm2]

@alrz I agree, this should be intersection types. Nitpick, they would both be definitely assigned. The proposal says they are set to null.

[gulshan]

Borrowing from Java, using union type(or intersection type, what's the difference in .net?)-

catch (CommunicationException|SystemException ex) {
    //handle it ex.
}

[Hosch250]

I was just about to propose this, but the syntax I chose was slightly different:

catch (ArgumentException)
catch (NullReferenceException)
{
    // `ex` provides the exception, like how `value` provides the set value for properties
    Debug.WriteLine(ex.Message);
}

This makes it somewhat more like a switch statement with multiple cases sharing a block of code.

[HaloFour]

@Hosch250

Omitting the exception variable is currently valid and means that you are discarding the instance of the exception. It would be inconsistent for it to mean something else there. Also, you also run into local shadowing issues by having an implicit local injected into scope. For properties that's not an issue since the only parent scope is the fields of the class which you could always reference via this. Lastly, I personally hate the abbreviation ex and prefer to type out exception in my code. I'd hate the compiler to force a naming convention upon me like that.

[jnm2]

I like this:

catch (ArgumentException ex)
catch (NullReferenceException ex)
{
    // ex is best common type now, and one day an intersection type.
}

[lachbaer]

@jnm2
That could lead to accidentally omitting the {} after the first catch, resulting in an unwanted behavior.
Therefore something like the ored version seems more stable to me.

[gulshan]

Linking my union and intersection types proposal- #399