Apollo-client: Suggestion: don't throw an exception on a cache miss

[jamesreggio]

This is a minor inconvenience that is likely a huge pain to fix, so take with a grain of salt.

It's generally an antipattern to use exceptions for ordinary control flow. They're more difficult to reason about; they incur multiple expensive stackwalks throughout their lifecycle; and, most importantly, they're annoying as hell when debugging.

The final point is most relevant here. Many JavaScript app frameworks include top-level exception handlers, which then require you (as a developer) to break on __all__ exceptions when debugging an issue. (The top-level handlers handle all exceptions, which makes breaking on __unhandled__ exceptions useless.) Unfortunately, Apollo Client presently relies upon exceptions to signal cache misses, which can be quite noisy for these debugging scenarios.

Removing these exceptions was discussed a bit in #1971, but it doesn't appear that exceptions-for-control-flow were removed in 2.0. It's probably too late to remove them now (since the exceptions are arguably a part of the API contract between the client and cache), but it's be great to put their removal on the roadmap for the next major release.

cc: @peterpme, who shares in this complaint.

[jbaxleyiii]

@jamesreggio @nevir and I have talked about this as well. I 100% think we should remove all internal try / catches to make developing a cache sane (its sooo hard to build one with the try catch in place) and because it will be faster.

[nevir]

Yes please! :P

[hwillson]

To help provide a more clear separation between feature requests / discussions and bugs, and to help clean up the feature request / discussion backlog, Apollo Client feature requests / discussions are now being managed under the https://github.com/apollographql/apollo-feature-requests repository.

Migrated to: https://github.com/apollographql/apollo-feature-requests/issues/24