Erlang/ets: reset ets table after getting a “bad argument”?

Question

I\'ve been learning how to use ets, but one thing that has bothered me is that, occasionally*, ets:match throws a bad argument… And, from them on,

Answer 1

Dale already told you what happens. You can confirm that by calling self() in the shell every now and then.

As a quick workaround you can spawn another process to create a public table for you. Then that table won't die along with your shell.

1> self().
<0.32.0>    % shell's Pid

2> spawn(fun() -> ets:new(my_table, [named_table, public]), receive X -> ok end end).
<0.35.0>    % the spawned process's Pid

3> ets:insert(my_table, {a, b}).
true

Now make an exception and check that the table indeed survived.

4> 1/0.
** exception error: bad argument in an arithmetic expression
     in operator  '/'/2
        called as 1 / 0
5> self().
<0.38.0>   % shell's reborn, with a different Pid

6> ets:insert(my_table, {c, d}).
true
7> ets:tab2list(my_table).
[{c,d},{a,b}]    % table did survive the shell restart

To delete the table, just send something to your spawned process:

8> pid(0,35,0) ! bye_bye.
bye_bye
9> ets:info(my_table).   
undefined

Answer 2

Although I'm not 100% sure, this thread seems to answer your question. It appears that you're observing this behaviour in the shell. If so, two facts are interacting in a confusing way:

1. An ets table is deleted as soon as its owning process dies.
2. The erlang shell dies whenver it receives an exception and is silently restarted.

So, when you get the first exception, the current shell process dies causing the ets table to be deleted, and then a new shell process is started for you. Now, when you try another ets:match, it fails because the table no longer exists.