[PD-dev] pd_error() for udpsend, tcpsend, etc.

IOhannes m zmoelnig zmoelnig at iem.at
Thu Jul 8 08:50:41 CEST 2010


On 2010-07-07 04:03, Hans-Christoph Steiner wrote:
> 
> Hey Martin,
> 
> 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[1] 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) [2]

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]
anyhow.


fga,sdr
IOhannes




[1] this is not entirely true. e.g. in Gem virtually all Object-emitted
errors are posted using pd_error().

[2] 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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20100708/9cb34ea3/attachment.bin>


More information about the Pd-dev mailing list