I like the idea, I know I've been bitten by :crypto myself, but I agree with Myron - submitting PRs to OTP seems like a better path since the whole BEAM community benefits.
Paul On Thu, May 26, 2016 at 10:17 AM, Ben Wilson <[email protected]> wrote: > I chatted briefly with Jose and James about this, and it seems we're > between a rock and a hard place a bit. > > The issue is that erlang itself doesn't really have much by way of error > messages. In the case of :ets for example it's literally just `:badarg`. > What's worse is that in the case of :ets people pretty frequently try to > catch specifically the `:badarg` value, so any changes would be breaking > and seriously so. > > :crypto is a little better because it's relatively rare to catch crypto > errors, so we could at least return stuff like {:badarg, Key} or something, > but the situation isn't great. > > On Thursday, May 26, 2016 at 11:11:16 AM UTC-4, Myron Marston wrote: >> >> Maybe we could submit PRs to Erlang/OTP itself to improve the error >> messages. That way, it helps Erlang developers and helps us :). >> >> Myron >> >> On Thursday, May 26, 2016 at 4:53:55 AM UTC-7, Ben Wilson wrote: >>> >>> Well on further reflection my implementation id isn't gonna work easily. >>> The basic idea with Ets specifically was to have a struct that included the >>> various options used and to use that info to return better error messages >>> in the event an error was raised. My thought was that that would only be >>> done on error, so that it didn't incur much overhead in the happy path. >>> This fails with just passing in a name though obviously so that won't work. >>> Possibly there's some :ets debugging functions that could be used, I'll >>> look into it more if there's interest. >>> >>> Crypto is easier. We know that keys have to be a certain byte width for >>> example, so we just bake those checks into the elixir side and call out to >>> `:crypto` if it's ok, otherwise return a useful error message. >>> >>> Thoughts? >>> >>> - Ben >>> >>> On Thursday, May 26, 2016 at 7:49:31 AM UTC-4, Ben Wilson wrote: >>>> >>>> I hit post too early, please hold... >>>> >>>> On Thursday, May 26, 2016 at 7:49:20 AM UTC-4, Ben Wilson wrote: >>>>> >>>>> Hey folks! >>>>> >>>>> I was prompted down this mode of thinking after answering some >>>>> questions related to why `:ets` was returning argument error. Turns out >>>>> they hadn't included the `[:named_table]` option. However the error >>>>> message >>>>> gave them exactly zero help when it comes to figuring out what is wrong. >>>>> >>>>> `:crypto` is another good example where any number of things can go >>>>> wrong, and all will result in the same generic argument error. >>>>> >>>>> There's really two questions here: >>>>> >>>>> 1) Is it worth wrapping something like :ets or :crypto with an elixir >>>>> module that could improve error messages? >>>>> >>>>> 2) Does this particular implementation idea I have sound reasonable? >>>>> >>>>> I split it up this way of course because while #2 may be a bad idea, I >>>>> don't want rejection of #2 to imply rejection of #1. >>>>> >>>>> >>>>> ## Implementation notion. >>>>> >>>>> By way of example, let's tackle that :ets problem >>>>> >>>>> Ets.new returns %Ets{opts: [:named_table], ets_id: 123987} >>>>> >>>>> defmodule Ets do >>>>> >>>>> end >>>>> >>>> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/719c979e-d8cd-4701-9752-e24f5cffb441%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/719c979e-d8cd-4701-9752-e24f5cffb441%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TutzycNJSBvRsMXnSdbr4hJw%2BR%3Dumo_R9f-Xh9UzXrcwg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
