Hi Kevin, Thanks for your proposal!
You can include any additional fields when defining exceptions, for example: defmodule MyError do defexception [message: "Ups!", code: :unknown] end and then give values to those additional fields in raise: raise MyError, code: :my_error_code assert_raise returns the rescued exception, so you can assert on any field after that: error = assert_raise MyError, fn -> raise MyError, code: :my_error_code end) assert error.code == :my_error_code Would that work for you? :) On Thursday, January 16, 2020 at 5:37:02 AM UTC+1, Kevin Johnson wrote: > > Any perspectives on this proposal? > > On Friday, December 27, 2019 at 6:59:34 PM UTC-5, Kevin Johnson wrote: >> >> As mentioned in the documentation >> <https://hexdocs.pm/ex_unit/ExUnit.Assertions.html#assert_raise/3>, >> `assert_raise/3` in all its glory allows us to supply a `message` as a >> `String` or even as a `Regex`. >> >> I *personally* have a preference to abstract away from specific message >> content in my tests as tests should not fail on account >> of an update to the grammar/phrasal of a given error message. >> >> To illustrate with a practical example, instead of writing a test like >> this: >> test "Required presence `Feature`-token" do >> assert_raise(SyntaxError, "Missing `Feature`-token", fn -> >> """ >> #language:en >> """ >> |> parse >> end) >> end >> >> One could instead abstract away as follows: >> test "Required presence `Feature`-token" do >> assert_raise(SyntaxError, :missing_feature_token, fn -> >> """ >> #language:en >> """ >> |> parse >> end) >> end >> >> That one `error_code` `:missing_feature_token` essentially summarizes >> the entire error message I may wish to benevolently display to the >> *end-user-in-agony*, >> which may be a short phrase or even a concise paragraph. Whatever may be, >> none of that prose needs to leak inside the dark corners of my test suite >> and an 'error code' >> seems to be very helpful to achieve this objective. >> >> My suggestion, if it deems your approval, would require: >> >> 1. Introduction of `error_code`(or whatever is semantically more >> sane) inside the relevant defexception >> >> <https://github.com/elixir-lang/elixir/blob/cd9253d1027bf8c0b0d34cb6ccd98f1a7b872d3e/lib/ex_unit/lib/ex_unit/assertions.ex#L4-L7> >> 2. Modification of def assert_raise >> >> <https://github.com/elixir-lang/elixir/blob/cd9253d1027bf8c0b0d34cb6ccd98f1a7b872d3e/lib/ex_unit/lib/ex_unit/assertions.ex#L377-L435> >> >> Above, I have volunteered my suggestion in the context of a practical >> need which happens to be fulfilled by resorting to an `error_code` as an >> `atom`. >> I have a limited imagination, so I hope that others can help >> explore/share better alternatives. >> >> >> -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/5afad200-212f-443a-8a69-8900c7b05565%40googlegroups.com.
