# 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-requ...@lists.iem.at
<mailto:pd-dev-requ...@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/>
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
