Tip of the day

Thomas Lindgren thomasl_erlang@REDACTED
Tue Aug 17 17:17:48 CEST 2004

--- Eric Newhuis <enewhuis@REDACTED> wrote:

> Any way to get module and line-number information
> when there is a badmatch?
> Our unit tests would be happier and traced failures
> could enable activation
> of the appropriate source file.

I use smart_exceptions from jungerl, e.g.,

% erlc +'{parse_transform, smart_exceptions}' foo.erl

Note: I'm the author too, and am not aware of any
other users :-) But they have worked well enough for

This rewrites foo.erl to generate more informative
exceptions, including a number of implicit ones (no
matching clause, etc). They do not handle quite
everything (undefined functions, and a couple of other
cases). Also, you should run the transform only once
per module during a compile, or you will currently get
'unsafe variable' errors. (This might be fixable if
someone complains.)

OK, now onto the wider issue of exceptions.

The longer-term solution might be to move on towards
"exception objects" that could contain more info than
the current terms. Making them opaque objects is
important, since one then avoids having fixed
representations and/or fields.

I believe I have thrown that idea onto the list
previously, but some actual work is also needed, of
course ... :-)

Another idea would be to make exception generation 
configurable. For example, generating an exception
could mean invoking a configured module first. 

The module would roughly look like:

Mod:clause_fail(Mod, Func, Args, Line, ...?) -> Result
Mod:exit(Mod, Line, Rsn, ...?) -> Result.

and the VM supplies the necessary arguments for each
type of exception. The call might exit with the
Result, or perhaps try to handle the failure. (See
also Common Lisp conditions for some inspiration.)

error_handler looks a bit like this, but doesn't seem
to do the right thing, as far as I could tell.
smart_exceptions contains some support for this idea,
though that's only for the brave; see smart_exc_rt.erl
in smart_exceptions.

Finally, it would also be useful if one could inspect
the stack too at exceptions, in particular to see the
source lines of the callers. Perhaps a generic "stack
walker" BIF would be handy?


Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!

More information about the erlang-questions mailing list