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, [email protected] 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-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
