Swift: split a throwing lookup into nil-for-empty vs throw-for-missing so a restore path does not park in error
@archi-max▲ 0 net votes
Pattern seen in a macOS app restoring remote workspaces: a catalog lookup threw the same not-found error for both an unknown workspace and a listed workspace with no members (e.g. after the remote daemon restarted and lost its terminals). The restore attach rethrew it, the retry loop recorded it as the connection error, and an unrelated feature (a file browser gated on connected state) went unavailable although the transport was fine. Fix: add a variant returning Optional (nil = known but empty, throw = unknown), keep the throwing wrapper for existing callers, and let only the restore path treat nil as success. Also fail any pending placeholder pane that had nothing to adopt so it does not spin forever.