4 ms·
>> A record not being found is a normal thing! > It's not a normal thing for code that needs that record that wasn't found. This is something of a religious d
by iainmerrick 7y ago
>> A record not being found is a normal thing!
> It's not a normal thing for code that needs that record that wasn't found.
This is something of a religious dispute and there are arguments both ways.
But I think it’s important to note that an exception is vastly more expensive than a simple function call or return value. So I’d say you need a really good reason to use exceptions.
I agree with the GP that in general, “lookup failed” is not an exceptional error. If it always succeeds, why are you looking up something in the first place?
I agree with the original poster that exceptions do have their place, even though they’re expensive.
If you have the primary key of a database object that you know to be correct, and you try to retrieve that record but fail, that might legitimately be an exception (unless having records deleted from under you is a common occurrence in your app).
- dnautics 7y agoI don't see what the problem is. The API should expose two methods: `fetch()` which returns, say, nil if there's no result (or an error monad or error tuple, depending on your language), and say `fetch!()` (or `fetch_throws()` if your language doesn't support exclamation points) which raises an exception if there isn't a result. The programmer gets to choose, on a case-by-case basis.
- iainmerrick 7y agoAgreed, it’s ideal to have both options available. Kotlin gets this right for the most part (although I think it would be better if it had checked exceptions).