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, all subsequent calls (even calls which previously worked) also throw a bad argument
:
> ets:match(Tid, { [$r | '$1'] }, 1). % this match works... % Then, at some point, this comes up: ** exception error: bad argument in function ets:match/3 called as ets:match(24589,{[114|'$1']},1) % And from then on, matches stop working: > ets:match(Tid, { [$r | '$1'] }, 1). ** exception error: bad argument in function ets:match/3 called as ets:match(24589,{[114|'$1']},1)
Is there any way to "reset" the ets
system so that I can query it (ie, from the shell) again?
*: I haven't been able to reproduce the problem… But it happens fairly often while I'm trying to do "other things".
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:
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.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.
Now make an exception and check that the table indeed survived.
To delete the table, just send something to your spawned process: