You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#921 which just got merged added a ReturnValue property to IInvocation, which allows user code to find out what got returned from a mocked invocation. The author of that PR (@MaStr11) suggested that an Exception property also be added for similar reasons; if an invocation throws, user code might want to find out what it threw.
I think we ought to add Exception Exception { get; } to IInvocation for completeness. Incidentally, we'd then reach parity with Moq 5 in this particular regard.
Some implementation notes
I mentioned in that PR that the addition of an Exception property wouldn't make Invocation heavier (by adding a corresponding field). The existing field Invocation.returnValue could serve double duty (holding either a return value, or an exception). We'd need to ensure that methods returning an exception as a regular return value should not report that via the new Exception property.
Also [mentioned in the PR] is the likely Moq code location where Exception would be set.
The text was updated successfully, but these errors were encountered:
P.S. @MaStr11: In case you were wondering where we stand regarding thrown exceptions, I didn't forget about it, but thought it would be cleaner to do that in a separate PR, to keep this one as straightforward as it was.
If you would like to submit a PR that adds an Exception Exception { get; } property to IInvocation (as you described in (1) above), please feel free to do so, and I'll merge that, too.
It shouldn't be too hard to do, setting the Invocation.Exception property would likely happen in a catch block being added there. (Ideally, we would make this addition without adding a new field to Invocation—to keep it as lightweight as possible–but that's not essential, it'd be more of an optimization. The existing returnValue field could serve double duty since an invocation cannot both return a value and throw. We'd only have to make sure that returned Exception objects won't leak out through the Exception property; this could be done by wrapping thrown exceptions in an internal type that only we can check for.)
#921 which just got merged added a
ReturnValue
property toIInvocation
, which allows user code to find out what got returned from a mocked invocation. The author of that PR (@MaStr11) suggested that anException
property also be added for similar reasons; if an invocation throws, user code might want to find out what it threw.I think we ought to add
Exception Exception { get; }
toIInvocation
for completeness. Incidentally, we'd then reach parity with Moq 5 in this particular regard.Some implementation notes
I mentioned in that PR that the addition of an
Exception
property wouldn't makeInvocation
heavier (by adding a corresponding field). The existing fieldInvocation.returnValue
could serve double duty (holding either a return value, or an exception). We'd need to ensure that methods returning an exception as a regular return value should not report that via the newException
property.Also [mentioned in the PR] is the likely Moq code location where
Exception
would be set.The text was updated successfully, but these errors were encountered: