mirror of
https://github.com/icsharpcode/ILSpy.git
synced 2026-10-12 02:15:58 +00:00
Siegfried Pammer
3cb27b0dcc
One member the decompiler could not handle aborted the whole export, so a single unsupported method in a large assembly left the user with nothing: no sources, no .csproj, no way around it. Recovering silently would trade that for a worse outcome - broken output nobody knows is broken - so every failure is recorded, written where the content would have gone, and pointed at the issue tracker. The recovery has to hold for anything the export touches, not just method bodies: a file that cannot be created, a resource that cannot be decoded, an output visitor that throws mid-type. Each of those costs its own unit and nothing else, and the units behind a failure are still produced - dropping them would make the export look complete when it is not. Consumers that relied on the exception keep their failure signal: ilspycmd exits non-zero and lists the failures, the PowerShell cmdlets raise an error record per failure, and the round-trip suite asserts the export reported none - otherwise a crash on a method its own tests never call would ship green. Assisted-by: Claude:claude-opus-5[1m]:Claude Code