debug tips?

[Lyn Headley]

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.

Lyn

--- 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,
> though.
> 
>
http://www.erlang.org/ml-archive/erlang-questions/200310/msg00237.html
> 
> (Adding some nice way to categorize exceptions would
> be useful too. Inheritance, anyone? :-)
> 
> Best,
> Thomas
> 
> 
> 
> 		
> __________________________________ 
> Discover Yahoo! 
> Stay in touch with email, IM, photo sharing and more. Check it out!
> 
> http://discover.yahoo.com/stayintouch.html
> 



		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html