Open alx9r opened 6 years ago
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.
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"?
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).
This PR demonstrates one way of supporting assertion on child exceptions for discussion. It would support the following usage:
Notes:
Get-ChildException
is similar to that of the ubiquitousGet-ChildItem
.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]
fromAssert-Throw
very useful on its own for chaining because the exception thrown could depend on theAllowNonTerminatingError
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.