Wrapping erlang modules with notoriously bad error messages

[Ben Wilson]

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

[Ben Wilson]

I hit post too early, please hold...

[Ben Wilson]

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

[Myron Marston]

Maybe we could submit PRs to Erlang/OTP itself to improve the error messages.  That way, it helps Erlang developers and helps us :).

Myron

[Ben Wilson]

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.

[Paul Schoenfelder]

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

--
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-co...@googlegroups.com.

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.