I had a brief look at the yield keyword when trying to understand the original question (seems to have emerged in C#, when I've never really gone beyond C++ in the main branch of that family) and I'll admit that I was left wondering what was wrong with a pass-by-reference into the test sub, or sub-stack, of an initially null object (or trivially-populated object/array/record/linkedlist-root, according to taste), into which you can pack all pertinant auxilluary return information, independent of the main function return value.
Then if you have a return value that indicates failure (e.g. negative integers give error codes, if all successes generate positive ones, which makes for an easy test, but depends on purpose, etc) you have accessible detail aplenty, including an enclosed object to be 'fixed', if necessary.
Or else probe probevalue.success as FIA as the way to decide whether or not you can even use the return value or must try to bounce back with whatever is held in probevalue.faileditem, or whatever you prefer.
Or is that a currently depricated programming paradigm that I should immediately desist in using? (It can be written in an obfuscated and nigh-on in decision herable manner, but mostly its as good or bad as your general structural style. Whereas "yield" just seems to be a strange command, compared to my usual and long-standing ways of implementing iterators (and homegrown things that I now realise are iterators) in the various computer languages and dialects I tend to dabble in.)