[PD] Ability to access error messages from patch
IOhannes m zmoelnig
zmoelnig at iem.at
Thu Jun 17 13:25:32 CEST 2021
(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.
in any case: ith the error outlet i think we really want a possibility
- get the error string as well
- suppress the internal error message (as it can now be handled on a
> # 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.
which of course could happen to be the same as the system error numbers
- as long as they are not system *specific*.
iirc POSIX defines error names, but not their values.
so probably its better to come up with your own error numbers from the
> # (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.
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.
> 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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 840 bytes
Desc: OpenPGP digital signature
More information about the Pd-list