Re: [PD] Ability to access error messages from patch

[IOhannes m zmoelnig]

(argh. one of those emails that are lingering opened on my desktop, and were never sent...here you go:)

On 6/15/21 12:32 AM, Christof Ressi wrote:

# 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.

totally.


- get the error string as well

in any case: ith the error outlet i think we really want a possibility to both: - suppress the internal error message (as it can now be handled on a patch level)

# 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.

iirc POSIX defines error names, but not their values.

which of course could happen to be the same as the system error numbers - as long as they are not system *specific*. so probably its better to come up with your own error numbers from the start.

# (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.

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


well, there are uncatchable exceptions.












gmasdr
IOhannes

again, i think this is not necessarily a bad thing as it nicely groups the objects that one wants to monitor. Pd is a data flow language and I thikn the per-canvas paradigm maps well to the idea of data "passing through a danger zone" - which it can also leave as well. anyhow, i used that naming here as an input for brainstorming and for the sake of an analogy. anyhow, whatever the name, i think we also should not use [catch] as the proposed object name ;-) however, I do like oliver's idea of hooking up such a [catch]-like object in the object-tree.

OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list