Currently, NoThrowDag's are nice and simple; their return type is either the return type of their last step (if everything succeeds) or a NoThrowReturn{missing} if they fail.
In a private project, we've run into a case where---even on failure---it would be useful to have the intermediate results of upstream steps.
There are assorted ways this could be accomplished; one that could work (proposed by @kendal-s) is on failure to return a special type that the internal state of the results up to the point of failure, in addition to the basic NoThrowResult{missing} (which should still be returned, so that all warnings/errors are still captured.
I'd kind of like to keep the original basic implementation, but maybe we can add a special alternative function to transform!(dag, input) that's like transform_and_return_intermediates!(dag, input) or something, that always returns the intermediates (on success or failure) in addition to the original NoThrowResult? (I know use of "and" in function names is often a code smell; perhaps someone can come up with a better/alternative name.)
Currently, NoThrowDag's are nice and simple; their return type is either the return type of their last step (if everything succeeds) or a
NoThrowReturn{missing}if they fail.In a private project, we've run into a case where---even on failure---it would be useful to have the intermediate results of upstream steps.
There are assorted ways this could be accomplished; one that could work (proposed by @kendal-s) is on failure to return a special type that the internal state of the results up to the point of failure, in addition to the basic
NoThrowResult{missing}(which should still be returned, so that all warnings/errors are still captured.I'd kind of like to keep the original basic implementation, but maybe we can add a special alternative function to
transform!(dag, input)that's liketransform_and_return_intermediates!(dag, input)or something, that always returns the intermediates (on success or failure) in addition to the originalNoThrowResult? (I know use of "and" in function names is often a code smell; perhaps someone can come up with a better/alternative name.)