[PD] Ability to access error messages from patch

Christof Ressi info at christofressi.com
Mon Jun 14 16:11:14 CEST 2021

Ok, I think we have to seperate two things:

1) posting error messages

2) obtaining error codes

I think Roman is primarly interested in 2), so that his patches can 
programmatically deal with certain error conditions.

Of course, 1) and 2) can be combined into a single object, basically 
errno + strerror.

I just shudder at the thought that users would start parsing error 
messages. After all, error messages are meant for display and can change 
at any moment. In the future, error messages might even get localized.

I find it extremely important to add proper error codes from the start 
to establish good practices.

> i mean, there currently is no such thing and if you want to use it you 
> have to hope for the object author to implement it. 
Sure. But library authors could update their objects to introduce error 
codes. If well designed, error codes could be entirely optional, e.g. 
[errno] outputting -1 if no error code was set.


On 14.06.2021 15:55, IOhannes m zmoelnig wrote:
> On 6/14/21 3:33 PM, Christof Ressi wrote:
>> Here's another idea, which I don't really love, but which I would 
>> prefer over your proposed [canvaserror]:
>> Method calls which can generate an error send the error code to a 
>> global [errno] object and the user can query the current error state 
>> with a bang. This would be similar to 'errno' in C.
> but which error-code?
> i mean, there currently is no such thing and if you want to use it you 
> have to hope for the object author to implement it.
> the nice thing about the [patcherror] object is that no changes would 
> be required to whatever objects (apart from the patch that uses it, 
> obviously; but that's true for all solutions).
> i also like the possibility, to suppress error printout (e.g. when 
> opening an *optional* configuration file).
> and: it would allow us to catch *multiple* errors (e.g. if an object 
> emitted two errors in a row, without stopping to send something to the 
> outlet so we can query the errno).
> as well as being able to catch errors that are not triggered by a 
> message directly (think: delayed opening of a file; either because 
> this happens only when dsp is turned on, or even in a separate thread).
> gamdrs
> IOhannes
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210614/c1d100c9/attachment.htm>

More information about the Pd-list mailing list