fix: revert catch of nothing pullbacks with Zygote

[gdalle]

fix #713

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.99%. Comparing base (19803d1) to head (10366fc).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #714      +/-   ##
==========================================
- Coverage   98.00%   97.99%   -0.01%     
==========================================
  Files         121      121              
  Lines        6358     6342      -16     
==========================================
- Hits         6231     6215      -16     
  Misses        127      127              

Flag	Coverage Δ
DI	98.96% <ø> (-0.01%)	⬇️
DIT	95.92% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MilesCranmer]

Thanks for getting to this so quickly. Do you think you can release a new version with this patch?

[gdalle]

I was just wondering whether I should do anything more. Right now we're back to the old behavior with errors involving nothing at random locations.
Essentially when you call a DI operator which directly falls back on Zygote, you're okay. But when you call something more sophisticated which doesn't have a direct Zygote equivalent, a nothing will appear in the middle of the code and then there's no telling where things will blow up, but importantly, they will blow up in a way that you can't really try/catch yourself for lack of a predictable exception type.
I thought about introducing a custom exception like you said, but where do we draw the line? What if there's an array for which some elements are nothing and some are not (as you demonstrated? Should I recursively dive into substructures to check for nothingness? These questions made me think the default behavior of letting things error if the rule is not defined is the right choice. After all this is a Zygote problem, not a me problem?

[MilesCranmer]

I think this is fundamentally a Zygote problem; there's nothing that can be done in DifferentiationInterface.jl to solve it. It needs to be fixed within Zygote.jl itself by creating new return types for each scenario. Leaving it as nothing as-is is not ideal, but it's basically the least bad approach. Trying to handle nothing explicitly is too dangerous, because (1) sometimes nothing is real (a field of a struct could just literally be nothing), (2) sometimes nothing indicates no dependence, and (3) sometimes nothing indicates a lack of a rule.

No way to identify which of these three branches was hit without changing Zygote itself. In a perfect world there would be a NoTangent() and UndefinedTangent() return value from Zygote to help disentangle these.

[gdalle]

alright then, I'll release as-is