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
I'm defining a custom scope for running assertions in, so that I can collect all failures and report them at once, instead of one by one.
The scope is an IDisposable, so if wrapped in a using statement, then the Dispose can be called after a throw, and throw any assertion failures.
The problem lies with if there's assertion failures, and also the user's code within the scope threw an exception. (Probably NRE would be the most common).
Because the assertion failures would essentially run and throw in a finally block, then the actual user exception is lost.
Because the scope isn't a delegate, I have no control over executing the code, and so can't catch anything per see.
So the workaround is I'm using AppDomain.CurrentDomain.FirstChanceException to capture any thrown exceptions, and check if they're thrown within the assertion scope.
The problem is, that any thrown exception is passed to FirstChanceException, but then I can't tell if it was caught or actually bubbled up to the test.
I don't want to surface caught exceptions, for obvious reasons, I just want to include details on exceptions that would bubble up anyway, so that users have more visibility of this.
If I could subscribe to a CaughtException event, then I could remove those exceptions, and thus my logic should work as intended.
For now, I'm having to just report any FirstChanceException and provide a message to the user that this may have thrown or may have been caught/handled. I have no way of knowing.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is probably very niche, but here goes:
I'm defining a custom scope for running assertions in, so that I can collect all failures and report them at once, instead of one by one.
The scope is an IDisposable, so if wrapped in a
using
statement, then the Dispose can be called after a throw, and throw any assertion failures.The problem lies with if there's assertion failures, and also the user's code within the scope threw an exception. (Probably NRE would be the most common).
Because the assertion failures would essentially run and throw in a finally block, then the actual user exception is lost.
Because the scope isn't a delegate, I have no control over executing the code, and so can't
catch
anything per see.So the workaround is I'm using
AppDomain.CurrentDomain.FirstChanceException
to capture any thrown exceptions, and check if they're thrown within the assertion scope.The problem is, that any thrown exception is passed to
FirstChanceException
, but then I can't tell if it was caught or actually bubbled up to the test.I don't want to surface caught exceptions, for obvious reasons, I just want to include details on exceptions that would bubble up anyway, so that users have more visibility of this.
If I could subscribe to a
CaughtException
event, then I could remove those exceptions, and thus my logic should work as intended.For now, I'm having to just report any
FirstChanceException
and provide a message to the user that this may have thrown or may have been caught/handled. I have no way of knowing.Hopefully that makes sense!
Beta Was this translation helpful? Give feedback.
All reactions