I am looking for something like in this simplified example:
with\
%{key: true} <- result = a_function_returning_map()
do
:success
else
_ -> IO.inspect(result)
end
The with construct seems like a good fit for the stream of various actions that may fail and return different results. I can recognise which of them failed based on a specific “fingerprint” of the failure but would like to have full result too. Any suggestions? Or back to nested cases/ifs and Co.?
Well, I read it (thank you) and basically it says “Back to deeply nested cases/ifs and Co.”, although not because there’s no way to pass result value(s) down to else. Rather because the author believes it to be at all “bad” to match specific errors in the else block
You’re throwing away the parameter passed to the else block. It will receive the result of the expression that failed.
iex(2)> with %{key: true} <- Map.new() do
...(2)> :success
...(2)> else
...(2)> result -> IO.inspect(result, label: "fail")
...(2)> end
fail: %{}
That’s because I simplified the example down to the very core 
Normally I’d match things there. The question was about passing additional information/variable, which (leaving aside whether this is “good” or “bad”) I am unable to do. But in retrospect it may not make much sense, indeed 
It can be done with wrapping tuples, but it’s ugly. You have to do things like:
with {:ok, result} <- get_result(),
{{:ok, other_result}, result} <- {{get_other_result()}, result} do
:success
else
{_, result} -> IO.inspect(result)
end
If you find yourself in that situation, then it’s probably worth stepping back to look at the bigger picture for other design approaches.
But the basic fact is that those bindings available in the expressions and do block are no longer in scope during the else
Not quite. What about the suggestion to introduce a unified error struct? We went with that approach and it works pretty nicely. The error struct doesn’t have to be global to the whole app - in our case we have an error struct per app domain. This requires some plumbing code but in practice it’s not that much of work.
I see.Thank you. Didn’t think of that. Maybe because
indeed
Full ACK. Thanks once more.
Quite literally in fact
This comes later in the article section and it is very much OK. In fact similar to what I am used to do in other languages when justified. Here, I may not yet be as well-versed in Elixir as I am in numerous other languages but when I am confronted with a well confined piece of not-really-reusable business logic I rather take a dozen lines of the author’s perfectly readable “Bad Elixir” than the larger, more complex and less readable “Good Elixir” I think the else was added to the language at some point for a reason. And the fact that it actually enforces matching the failed expression is for a reason too. Obviously this shouldn’t be abused to create monstrous blocks of rather brittle code - that would be a completely different story.
The else clause was there from the beginnings of with. Looking through Elixir’s codebase, I haven’t really found instances of using more than one patterns in else. So it’s either falling through without the else clause:
def touch(path, time) when is_tuple(time) do
path = IO.chardata_to_string(path)
with {:error, :enoent} <- :elixir_utils.change_universal_time(path, time),
:ok <- write(path, "", [:append]),
do: :elixir_utils.change_universal_time(path, time)
end
or returning a default regardless of an error:
def parse_version(string, approximate? \\ false) when is_binary(string) do
destructure [version_with_pre, build], String.split(string, "+", parts: 2)
destructure [version, pre], String.split(version_with_pre, "-", parts: 2)
destructure [major, minor, patch, next], String.split(version, ".")
with nil <- next,
{:ok, major} <- require_digits(major),
{:ok, minor} <- require_digits(minor),
{:ok, patch} <- maybe_patch(patch, approximate?),
{:ok, pre_parts} <- optional_dot_separated(pre),
{:ok, pre_parts} <- convert_parts_to_integer(pre_parts, []),
{:ok, build_parts} <- optional_dot_separated(build) do
{:ok, {major, minor, patch, pre_parts, build_parts}}
else
_other -> :error
end
end
or using the approach suggested by the author, but without a dedicated error struct:
with :ok <- make_boot_scripts(release, version_path, consolidation_path),
:ok <- make_vm_args(release, vm_args_path),
:ok <- make_vm_args(release, remote_vm_args_path),
:ok <- Mix.Release.make_sys_config(release, sys_config, config_provider_path),
:ok <- Mix.Release.make_cookie(release, cookie_path),
:ok <- Mix.Release.make_start_erl(release, start_erl_path) do
consolidation_path
else
{:error, message} ->
File.rm_rf!(version_path)
Mix.raise(message)
end
I’m not familiar with the codebase, but the last one looks like a use of with to build some flow (something that you’d use in application code) rather than just mechanics of avoiding nested case (something you’d use more in library code)
Correct. I generally find having more than one clause in else an anti-pattern. We either use it as a “catch-all”, otherwise I prefer to have each function in with already return the proper types, as shown in your last example.
This source says: " As of Elixir 1.3, with/1 statements support else", which I interpret that it was added in 1.3. Correct me if I am wrong or the source is wrong.
I surely would prefer that too. But the reason why I wanted to use with was actually that I didn’t have that kind of comfort and it looked like an easy/elegant way of integrating a flow of different, non homogeneous steps without building a large, nested if/case bow.
© Copyright Elixir Forum | Terms | Privacy & Cookies
