IMHO, that's being a bit too ideological. It's better to think about it in terms of how you'd want to respond to the condition, and pick your tool appropriately.
For instance, if I'm asking for a record by ID, then a record not found exception is a good fit. I was probably going to do something with the record, but now I can't, and the exception idiom tool the condition to be dealt with where it happened even if I forget.
If I'm asking for a set of records matching a criteria, and nothing matches, then a record not found exception is a poor fit. Code that can deal with a populated list usually can deal with an empty list just fine, and using an exception just adds friction.
If I'm asking for a set of records matching a criteria, and the database is is down, then an empty list is a poor fit. I have information about the connection error I need to communicate, so it's better to use an exception.
This isn't something you can make universal statements about, because it depends on context.
If the program knows it just put or saw the record there, is it strange to assume it's still there? If the program completely controls the database and something else in it implies the record is there, is it still strange to assume?
Sometimes broken assumptions can only signify that something has gone very wrong, and it's not worth handling them at a fine-grained level. That leads to the "gotta catch em all" antipattern the article mentions.
This just isn't true. It depends on what the record is, and what state you're in (aka: CONTEXT).
incredibly clear example: 1. User logs in 2. User record no longer exists 3. Exception
That's not a recoverable situation, and the client should see that as an unexpected error.
> This just isn't true. It depends on what the record is, and what state you're in (aka: CONTEXT).
These two things mean the same thing. It's in the context - > it is not an inherent property.
It's not an inherent property - > it's not always present.
Some conclude therefore it shouldn't be an exception by default.
>Anyone who expects a database to always have records and that the absence of a record is an "exception" has a very strange way of thinking.
But pedantics aside, my point stands. There are absolutely contexts and code paths where a missing record is basically unrecoverable. Why bother returning an error to the local calling context when you know that code doesn't make sense anymore and can't recover? A jump to a new code path is the right call, and exceptions do that (with a lot of nice trace information about why we ended up on that new code path to boot).
Doesn't mean a missing record should always result in an exception, but it's certainly not a "very strange way of thinking".
Then again, maybe there are cars built that way. Oy vey.
I would never expect that a call to `Record.find(...)` would always find records, and that the failure to find a record means that something is broken. The absence of data is usually all you need to handle control flow, and treating absence as a failure is presumptuous of API engineers. Having to account for a specific exception just adds more lines of code that could be easily avoided.
A better use of an exception would be for a system failure like this: "Connection Failed"