[PD] Ability to access error messages from patch

[Christof Ressi]

# error outlets

> Let's say.... if we were to consider adding some sort of "standard 
> outlet" for errors, how many objects are we talking about? I assume 
> not every object but perhaps those which read/write files and the net 
> objects? That's not so many, really.
I agree. We should ask ourselves if it is really necessary to add some 
generic error reporting mechanism to Pd. Error outlets are certainly the 
most simple and most easy to understand solution from a user perspective.

# errno object

> As Pd is more or less structured after C to some degree, I like the 
> idea of formalizing something like errno and simply using the standard 
> defined error numbers
When proposing the [errno] object, I did not mean that it would output 
the C errno, but rather custom error codes as defined by each object.

# (sub)patch errors

Another disadvantage is that you need to have the object in a dedicated 
subpatch, otherwise you have to use complicated [spigot] logic to deal 
with crosstalk between several objects.

Christof

On 15.06.2021 00:11, Dan Wilcox wrote:
> (Resending to pd-list after respond to wrong post.)
>
> Some quick thoughts on my end.
>
> # error outlets
>
> Let's say.... if we were to consider adding some sort of "standard 
> outlet" for errors, how many objects are we talking about? I assume 
> not every object but perhaps those which read/write files and the net 
> objects? That's not so many, really. I already added a general "info" 
> outlet for [soundfiler] which could easily be extended by outputting 
> an error list ala "error # msg symbols..." or simply "errno."
>
> One negative is that this sort of approach becomes relatively 
> arbitrary and supported by only a few objects, some which may have a 
> dedicated error outlet and others which may have a generalized outlet 
> with some sort of error list selector etc. OTOH the growth of Pd's 
> objects over time has ensured this kind of "arbitrariness" is part and 
> parcel, so maybe it is less so.
>
> A positive point is that it's relatively easy to communicate and work 
> with. For instance, we have this paradigm to a small degree where 
> [netrecieve] will output a 0 if the connect message failed.
>
> # errno object
>
> As Pd is more or less structured after C to some degree, I like the 
> idea of formalizing something like errno and simply using the standard 
> defined error numbers. At least there is something already to use, 
> however the standard values are probably not enough to cover all cases 
> but at least "can't open file" or "unsupported parameter" etc are there.
>
> This would force a certain design paradigm where you need to do A then 
> check error, then maybe do B and check error, etc. Sure, that's how 
> you do it in C, for most things, but it's also a lot of boilerplate 
> and boilerplate is much more annoying in a patcher.
>
> # (sub)patch errors
>
> I find a sub(patch) level error object enticing, ie. anything in this 
> (sub)patch will throw an error to this object. I think IOhannes called 
> them exceptions, but I would avoid that naming as I assume it will not 
> halt or crash Pd if the error is not handled.
>
> Like errno, this would force a certain design paradigm where you need 
> to group object + error object all the time. In some cases it wouldn't 
> bother me and in others I'd find it annoying. It would be simple to 
> communicate however and relatively easy to integrate into Pd by, I 
> assume, a new API call where objects can raise a "patch level" error 
> as opposed to global stdout/stderr all console.
>
>> On Jun 14, 2021, at 11:25 PM, pd-dev-request at lists.iem.at 
>> <mailto:pd-dev-request at lists.iem.at> wrote:
>>
>> 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.
>>
>> If the user queries the errno immediately after the method call, Pd's
>> determinism guarantees that the error really belongs to that method
>> call. We would have to reserve a special value (e.g. "0") to mean "no
>> error".
>>
>> My main point is that errors should not be *sent* by global or
>> canvas-local objects, but that they should be *queried*. This way the
>> user doesn't have to deal with cross talk between different objects.
>
> --------
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210615/07524e24/attachment-0001.htm>