On 2010-07-07 04:03, Hans-Christoph Steiner wrote:

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)