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.
For more options, visit https://groups.google.com/d/optout.
