Sat Jun 4 20:03:18 CEST 2005
In case more opinions are welcomed, I'd like to add that in
learning erlang I've found the lack of stack traces in exceptions
to be a serious impediment. Perhaps this is laziness on my part
for not thoroughly exploring and learning the available erlang
style methods (for information concerning which I appreciate Ulf
Wiger's recent post). But I find tracing to be sometimes a clumsier
solution and find myself wishing for a stack trace.
--- Thomas Lindgren <thomasl_erlang@REDACTED> wrote:
> --- "ke.han" <ke.han@REDACTED> wrote:
> > I feel like there must have been a better way to
> > close in on the error
> > than what I did. For example, is there a way to get
> > a report when
> > another process "throws" an error.
> You can monitor other processes with the trace BIF and
> the dbg module, though I can't say whether it helps in
> this case.
> > What if I have
> > no idea, as in this
> > case, how the error was generated..the "error" tuple
> > was simply passed
> > back to the Client process. Any suggestions?
> I'd like more informative exceptions too. I tend to
> use my smart_exceptions package (see Jungerl) as a
> compiler prepass. This adds module, line number, etc.
> to the exception ... but that only helps for code you
> have compiled yourself, and, since R10, causes masses
> of (useless) warnings from the compiler to boot. The
> real solution would be to extend the runtime system,
> (Adding some nice way to categorize exceptions would
> be useful too. Inheritance, anyone? :-)
> Discover Yahoo!
> Stay in touch with email, IM, photo sharing and more. Check it out!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
More information about the erlang-questions