4 comments

[ 2.9 ms ] story [ 20.9 ms ] thread
If you have a method called getUser and it throws an error when it can’t get a user, It’s much easier on the consumer to spell this out explicitly with a name like getUserOrThrowError

I think this is bad advice honestly. Who does this anyway?

Plenty of languages have this convention. For example, in Elixir it's customary to have something like `getUser` that returns either {:ok, the_user} or {:error, reason} alongside `getUser!`, the `!` indicating that in case of error it will throw.

Of course, a better approach is to not throw at all, and leverage a type system to force the consumer to deal with potential error: `getUser: Try[Option[User]]` for example. More verbose, and forces you to handle all the cases, but safer and less error prone.

I like that it isn't directed at any specific language but can be taken for whichever language the reader wants. Mostly good advice!
Don't agree with all the items, but it's refreshing to read a post where "API" is not used as a synonym for "REST API" or even "Web API".