From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani
In "emacs -Q", load the modules/mod-test/mod-test module, the= n try
this:
=C2=A0 M-: (mod-test-sum "1" 2) RET
Result: Emacs aborts.=C2=A0 This happens because the eassert in
module_extract_integer aborts, when that function is called for the
2nd time:
=C2=A0 static intmax_t
=C2=A0 module_extract_integer (emacs_env *env, emacs_value n)
=C2=A0 {
=C2=A0 =C2=A0 check_main_thread ();
=C2=A0 =C2=A0 eassert (module_non_local_exit_check (env) =3D=3D emacs_funca= ll_exit_return);
=C2=A0 =C2=A0 Lisp_Object l =3D value_to_lisp (n);
=C2=A0 =C2=A0 if (! INTEGERP (l))
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 module_wrong_type (env, Qintegerp, l);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
=C2=A0 =C2=A0 =C2=A0 }
The first call to module_extract_integer correctly detects the wrong
type of argument and calls module_wrong_type.=C2=A0 But module_wrong_type just records the problem in the env structure, it doesn't signal any
Lisp error, like an Emacs primitive would.=C2=A0 So the actual error goes undetected, and is masked by the assertion violation (because Emacs is
built with --enable-checking).
Since this obviously works as it was designed, my question is: how
should a module be written so that this kind of errors signal a normal
Lisp error we are accustomed with Emacs primitives?