(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.
in any case: ith the error outlet i think we really want a possibility to both:
- get the error string as well
- 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.
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 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.
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.
gmasdr IOhannes