Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Split that problem into two problems:

1. Your collaborator cannot be reached.

2. Your client has a network connectivity problem.

I've never seen a client who needs to know #1. All they care about is that there was a DataStoreGateway::TransientInsertError, and that TransientInsertErrors mean retrying and notifying the UI that their work hasn't been committed yet.

#2 isn't a problem the DataStoreGateway should be responsible for, because it will affect almost everything in the system in one way or another, and you don't want to have to write that code repeatedly. It's more likely a kind of Alarm--the kind of thing that gets pushed out from wherever it is to a global alarm handler, which then does something like putting the UI into a different root view-controller state, e.g. darkening it and covering it with a modal saying "lost connection."



Actually no, it was not either of those cases, it was what I said. The APIS that I'm working with aren't that much like a DataStoreGateway.

Your design points may be valid, but they don't really talk about mocks; why bend over backwards to avoid testing using a mock?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: