On 2010-07-07 04:03, Hans-Christoph Steiner wrote:
I've been using udpsend/udpreceive in a project and they've been great.
I have one small request, which I'd happily implement if you don't want
to. For the error like "not connected", it would be very handy if they
used pd_error() so that the error is findable.
i started doing this a while ago, and eventually stopped it again.
the reasoning behind this is:
as you have well observed, pd_error() allows you to find the error with
the find menu. the target case for this is patching errors (e.g. sending
a symbol to a float-only inlet) where you want to find the erroneous
code and fix it.
an error like "not connected" is very much unlikely to be caused due to
a patching error. it's more likely to be caused of user-error, e.g.
because the given remote host is unavailable.
"users" (as opposed to patchers) have a different role and are
potentially different people. i believe that they should have a
different feedback. (even if patcher and user are the same person, they
will gain more insight if they know right from the start whether the
problem is a syntax error or a logical error) 
it should be possible to get feedback within the patch for all errors
caused by user-input. so if you get "not connected", there should be a
way for the patch to know about this. if this is the case, you can
manually "throw" a findeable error by means of things like [canvaserror]
 this is not entirely true. e.g. in Gem virtually all Object-emitted
errors are posted using pd_error().
 thinking of this, i notice that in Gem there is only a single
error() handle for both syntax-errors and runtime errros. i guess i
should differentiate between these two kinds of errros (and probably
still use pd_error() as a backend for emitting the messages in both cases)