This is true. Maybe I ought to stop giving example error/exception-types when defining them, as it's always situation-dependent. I think there's a bit of a fuzzy line here as to what is counted as an "exception" and what is counted as an "error", and ultimately it's up to the API designer to decide what constitutes as "misusing the API". The general rule of thumb I follow is "when in doubt, use an error. You can always turn them into exception later if a need arises to handle it (unless you're in Java)".
It's completely reasonable to design arrays that throw an "IndexOutOfRange" exception, allowing users to recover from this issue. It's also reasonable to design an array where the designers expect you to always check your index before indexing into it, and any out-of-bound issues will be thrown as an error. Yes it's possible for the user to recover from it, but that's not how the designers want you to deal with this issue.
There are some cases where an error will always be an error, like, if your program got itself into a bad state and you caught that issue (a common use for asserts).
So I misspoke a bit when I tried to define these two terms, thanks @ljharb for pointing this out. Maybe this is a better definition:
- error = programmer error - you should never recover from these because they indicates there was a bug in the program (e.g. mis-used an API, program in a bad state, etc).
- exception = Something went wrong while doing a task. If wanted, you can choose to recover from this issue.