Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Get-ChildException approach to supporting assertion on child exceptions #28

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

alx9r
Copy link

@alx9r alx9r commented Nov 19, 2017

This PR demonstrates one way of supporting assertion on child exceptions for discussion. It would support the following usage:

{ throwsNestedException } |
    Assert-Throw |
    Get-ChildException -Recurse |
    Assert-Any {$_.Message -eq 'the error message I care about'}

Notes:

  • The behavior of Get-ChildException is similar to that of the ubiquitous Get-ChildItem.
  • The output from Assert-Throw is the [ErrorRecord] thrown not the input [scriptblock]. I'm not sure what the benefit of outputting the input [scriptblock] would be. I didn't find outputting the input [scriptblock] from Assert-Throw very useful on its own for chaining because the exception thrown could depend on the AllowNonTerminatingError parameter which the downstream functions don't have conclusive access to.

I'm mainly interested in whether you think this (or something similar) has a hope of making it into this project. I do have immediate need for assertions for nested exceptions, and I'd like to focus development in the appropriate place: Whether that's contributing to this project or some auxiliary library of my own.

implement Get-ChildException
export Get-ChildException
return [ErrorRecord] instead of [scriptblock] from Assert-Throw
@nohwnd
Copy link
Owner

nohwnd commented Nov 21, 2017

One thing that bothers me is that I don't see any benefit in using the Get-ChildException without the -Recurse switch, because then it's simpler to use .InnerException directly. That would mean that we are adding a cmdlet for single purpose of reducing the exception structure. This has potential to be a much more generic function, and maybe even part of the collection assertions. But maybe flatening structure like this is not so useful for PowerShell scripters, what do you think? Personally I need to think about it a bit more before commiting to an approach.

You are right about outputting the scriptblock, that does not make sense. Outputting the error is much better option Verify-Throw does it the same way.

@alx9r
Copy link
Author

alx9r commented Nov 21, 2017

One thing that bothers me is that I don't see any benefit in using the Get-ChildException without the -Recurse switch, because then it's simpler to use .InnerException directly.

Some exceptions have both an InnerExceptions and InnerException property. In that case Get-ChildException -Recurse could include unique instances of those exceptions as well.

But maybe flatening structure like this is not so useful for PowerShell scripters, what do you think?

Can you elaborate on what you mean by "PowerShell scripters"?

@nohwnd
Copy link
Owner

nohwnd commented Nov 21, 2017

Yes but what would the cmdlet without the -Recurse do better, than using .InnerException directly?

I mean that in PowerShell we don't often come across nested structures that are simple to flatten (like $e.InnerException.InnerException.InnerException.InnerException).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants