Johannes Zmölnig wrote:
> Matteo.sistisette wrote:
>> Often, when I get an error, such as for example "inlet: no method for
>> 'list'", and I do a "Find last error", I get the message:
>> ...sorry, I couldn't find the source of last error
> then there is a 2nd type of error message, which links a message to a
> certain object. when an object uses this special kind of error message,
> you will be able to track the error with the "find last error" menu.
> a C-programmer can often choose to use one of these variants;
> using the 2nd method is a tiny bit more complicated (and requires more
> typing); this is most likely the reason why people do not explicitely
> use it.
A while ago, I started replacing all error() calls by pd_error() calls so
that error messages can be located better. However, I am considering
removing pd_error() completely instead, using a system of
dynamic variables (in LISP parlance).
A dynamic variable is like a global variable that is being used as local
by backing up and restoring the contents of the variable whenever
appropriate. Most of the time this is equivalent to lexical variables
(the other kind of local variables) but in this case this also allows one
to use the contents of the variable as set by the caller, or the caller
of the caller, or whoever set the variable last (in terms of levels of
nesting). This makes pd_error() useless, as any error() call can look up
the variable that indicates the currently deepest method activation (last
message received that isn't yet finished handling). This allows
accurate error-reporting from functions that don't have a "this" parameter
and have no idea what it could be.
I introduced this feature in GridFlow a long time ago. (currently it's not
in GridFlow anymore, for reasons that are long to explain, but I still
think that it's a good idea)
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada