Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Capturing true/false #11

Closed
OvermindDL1 opened this issue Jan 12, 2017 · 3 comments
Closed

Capturing true/false #11

OvermindDL1 opened this issue Jan 12, 2017 · 3 comments

Comments

@OvermindDL1
Copy link

It would be quite convenient to be able to wrap up true/false into something that returns an exception if on false (maybe if on true via configurable option) or else passes the input value unaltered. An example:

# Assuming test_bool is a something like `safe` is in usage:
request_ip
|> get_client_ip(params)
|> Geoip.lookup_ip() |> normalize # normalize takes a tagged-tuple and converts it to an ErlangError or unwraps an :ok tuple
~> bool_test(should_search?/1).(parse_exclusion_zone(params)) # Here
~> build_search_query(%SearchQuery{}, params)
~> NGSearch.search() |> normalize
~> Analytics.track(client_ip, "api", "search_results")
~> (&json(conn, &1)).()
|> ensure!

Although with macro work could clean it up (and could clean up others, like safe as well).

Basically just return an ErlangError (preferably saying what failed, by saying the passed in 'should_search?/1' failed its test), else it returns the prior passed in value.

@expede
Copy link
Owner

expede commented Feb 17, 2017

What sort of exception would the boolean turn into? A few people have asked for automatic conversion in different forms, but there's always information loss versus using a case statement. I think that automation would be amazing if we can do it while preserving context & semantics. I'd love to hear your thoughts!

@OvermindDL1
Copy link
Author

What sort of exception would the boolean turn into? A few people have asked for automatic conversion in different forms, but there's always information loss versus using a case statement. I think that automation would be amazing if we can do it while preserving context & semantics. I'd love to hear your thoughts!

Could take that as an argument as well perhaps, maybe defaulting to one of the generic Elixir exceptions?

@OvermindDL1
Copy link
Author

This is solved by #18 basically, just without the piping part. ^.^

Close-worthy now or leave open for more thoughts?

@expede expede closed this as completed Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants