Re:How to design APIs that don't suck
by vmasto on Sunday October 23, 2016 @09:55AM
(#12773562)
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?
Re:How to design APIs that don't suck
by dudul on Sunday October 23, 2016 @10:52AM
(#12773796)
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 think this is bad advice honestly. Who does this anyway?
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.