4 ms·

{:ok, foo} is just the largely community adopted soft error pattern in elixir call_service could just return response and remove the verboseness. so it would

by Grimm1 5y ago

{:ok, foo} is just the largely community adopted soft error pattern in elixir call_service could just return response and remove the verboseness. so it would be: response <- call_service(data) I don't know C# but would that code explode if there was an error, instead of in again the soft error pattern likely getting {:error, foo} ? Regardless my point is that {:ok, bar} stuff isn't a language required aspect it's a community pattern if that makes it any better for you.

masklinn 5y ago
> {:ok, foo} is just the largely community adopted soft error pattern in elixir It is not a community pattern, because it's the way OPT (Erlang's "standard library") functions work e.g. maps:find? returns `{ok, Value} | error`. And Elixir inherited that rather directly and build its standard library the same way. `Map.fetch` similarly returns `{:ok, value()} | :error`. It's not hard-coded into either language, but it's absolutely not "community adopted" or "a community pattern" either.
- Grimm1 5y ago
  Clearly not every library uses it, and not everything in the standard library adheres to it either, just as you said where the Erlang tie ins are. What would you call something then that clearly has optional adoption and isn't consistently used across the standard library?
  - jolux 5y ago
    In Elixir’s standard library at least, it is pretty consistent. Functions that can fail return tagged tuples, and functions that will throw when they fail end in !.
    - Grimm1 5y ago
      Map.pop is one counter example. The failure mode is just {nil/default, Map} Unless you use Map.pop! which raises an error, and because pop! raises an error I would then expect Map.pop to return {:error, nil} or {:error, Map} or something instead of {nil/Default, Map}. I won't try to back up where/if there's more this is but it was the one I had in mind while writing.
      - jolux 5y ago
        Well yes, because not finding a key in a map is not an error typically. Map.get is the same way, as is Access. It returns nil. If you want it to be an error you can use the version that raises.
        Grimm1 5y ago
        That's not true across many of the languages I use, dict.pop returns a key error in python for instance. By having a version that raises the standard library is basically saying not having a key is the error state.
        jolux 5y ago
        > That's not true across many of the languages I use, dict.pop returns a key error in python for instance. Yeah, sorry. I should have been more clear. This behavior is common in Lisps, which is what I’m used to. It’s less common in mainstream languages. With Elixir it may be Clojure-inspired. > By having a version that raises the standard library is basically saying not having a key is the error state. Not necessarily, it’s saying you can choose whether it should be an error or not. Notably other functions that error don’t give you the option of specifying a default. That’s the difference here. Nil is returned because it’s passed in, it’s the default argument for the “default value” parameter.

by Grimm1 5y ago

masklinn 5y ago

> {:ok, foo} is just the largely community adopted soft error pattern in elixir It is not a community pattern, because it's the way OPT (Erlang's "standard library") functions work e.g. maps:find? returns `{ok, Value} | error`. And Elixir inherited that rather directly and build its standard library the same way. `Map.fetch` similarly returns `{:ok, value()} | :error`. It's not hard-coded into either language, but it's absolutely not "community adopted" or "a community pattern" either.

Grimm1 5y ago
Clearly not every library uses it, and not everything in the standard library adheres to it either, just as you said where the Erlang tie ins are. What would you call something then that clearly has optional adoption and isn't consistently used across the standard library?
- jolux 5y ago
  In Elixir’s standard library at least, it is pretty consistent. Functions that can fail return tagged tuples, and functions that will throw when they fail end in !.
  - Grimm1 5y ago
    Map.pop is one counter example. The failure mode is just {nil/default, Map} Unless you use Map.pop! which raises an error, and because pop! raises an error I would then expect Map.pop to return {:error, nil} or {:error, Map} or something instead of {nil/Default, Map}. I won't try to back up where/if there's more this is but it was the one I had in mind while writing.
    - jolux 5y ago
      Well yes, because not finding a key in a map is not an error typically. Map.get is the same way, as is Access. It returns nil. If you want it to be an error you can use the version that raises.
      - Grimm1 5y ago
        That's not true across many of the languages I use, dict.pop returns a key error in python for instance. By having a version that raises the standard library is basically saying not having a key is the error state.
        jolux 5y ago
        > That's not true across many of the languages I use, dict.pop returns a key error in python for instance. Yeah, sorry. I should have been more clear. This behavior is common in Lisps, which is what I’m used to. It’s less common in mainstream languages. With Elixir it may be Clojure-inspired. > By having a version that raises the standard library is basically saying not having a key is the error state. Not necessarily, it’s saying you can choose whether it should be an error or not. Notably other functions that error don’t give you the option of specifying a default. That’s the difference here. Nil is returned because it’s passed in, it’s the default argument for the “default value” parameter.