Represent try..catch without exception variable or filter using expression tree factory methods

Question

Which factory method in System.Linq.Expressions.Expression should I call to create an expression tree -- more specifically, a CatchBlock instance -- which represents the catch in the following C# code:

try { // ... } catch { // ... }

All the overloads of the Catch method seem to require either an exception type -- the equivalent of this:

catch (Exception) { // ... }

and/or a ParameterExpression which will be bound to the exception -- the equivalent of this:

catch (Exception ex) { // ... }

Passing null into the first argument (and casting to Type to avoid ambiguity):

// using static System.Linq.Expressions.Expression Catch((Type)null, Constant(true));

causes an ArgumentNullException.

The MakeCatchBlock method has the same behavior

AFAIK (and according to this post as well), try {...} catch {...} is equivalent to try {...} catch(Exception) {...} - so you can simply create a catch(Exception) {...} expression instead of catch {...} expression. — Zohar Peled
– Zohar Peled, Commented Mar 31, 2019 at 13:11
@CamiloTerevinto It seems that a plain catch is a valid way of handling non-CLS exceptions, which may not inherit from System.Exception. — user20416
– user20416, Commented Mar 31, 2019 at 13:27
@ZoharPeled The documentation indicates otherwise -- a plain catch will handle a non-CLS exception. — user20416
– user20416, Commented Mar 31, 2019 at 13:29
@CamiloTerevinto That answer has no references in support of its' claims, and the documentation page I linked to has been updated a number of times since .NET 3.0. This answer from the same question references the documentation page. — user20416
– user20416, Commented Mar 31, 2019 at 13:35
@ZoharPeled Did you read past the first bullet point? In C# you cannot throw non-CLS exceptions, but you can catch them in two ways: ... * Within a general catch block (a catch block without an exception type specified) that is put after all other catch blocks. — user20416
– user20416, Commented Mar 31, 2019 at 13:40

Zohar Peled · Accepted Answer · 2019-04-03 10:56:58Z

The usage of try {...} catch {...} to catch exceptions thrown from non .Net components and therefor don't inherit from System.Exception is misguided since the CLR automatically wraps such exceptions with a RuntimeWrappedException which obviously does inherit System.Exception - and therefor you can use try {...} catch(Exception e) {...} to catch thous exceptions as well.

Therefor, there is no need to handle the plain try {...} catch {...} separately from try {...} catch (Exception e) {...} since they both will catch all exceptions.

there really is no point of using try {...} catch {...} -- saving an extra variable declaration? But I was thinking the answer should be, since the two are equivalent, there is no need to handle the plain try {...} catch {...} separately from try {...} catch (Exception e) {...}. see here.

Collectives™ on Stack Overflow

Represent try..catch without exception variable or filter using expression tree factory methods

1 Answer 1

2 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

2 Comments

Linked

Related