You're right; if the only way to test for existence of something is to try and fetch it and check for an error state, then the API is forcing all the costs of i

You're right; if the only way to test for existence of something is to try and fetch it and check for an error state, then the API is forcing all the costs of its error handling on very regular uses. And if you're dealing with non-determinism, then even a pair of APIs which let you separate out existence-checking from fetches isn't enough; you just introduce a race. I like how .net does it with methods returning bool and an out parameter. Pattern matching on a return value would be fine too. It only makes sense on methods where you reasonably do need to handle the error case. And a variant which triggers an error condition on failure should exist too, for simpler programs which don't need to handle such failures, merely log them.