that's an excellent idea!
I think it could work like this:
[catch] has one inlet and two outlets. If you send a message to the inlet, the object will
reset the global (per instance) error state to a reserved value
forward the message throught he right outlet. This message would call
a "throwing" method in another object, which would in turn set the error state.
- output the current error state
There could be a public API method, e.g. pd_setlasterror(), which would set the current error code.
I think it would make sense to *always* output an error code, even on success, so we wouldn't need special logic to distinguish between success and failure. For example, 0 could always mean "no error".
Also, it might be useful to distinguish between "no error" and "unknown" (used in step 1).
If [catch] outputs "unknown", we know that the object didn't call pd_setlasterror(). This way we can write code that also works with older versions of the object.
Christof
On 14.06.2021 18:10, Miller Puckette via Pd-list wrote:
Here's another idea: a "catch" object that passes messages from inlet to outlet, but then reports errors (somehow or other) only when those errors occur while forwarding the message.
cheers M
On Mon, Jun 14, 2021 at 04:01:15PM +0200, oliver wrote:
Christof Ressi wrote:
i quite like the idea of having a canvas-scope for such an object.
Personally, I would rather prefer that if the error code would be simply output by the same object that generated the error.
that can take a long time, even for vanilla objects ;-)
and there are so many 3rd party objects out there that would all need to be modified and re-released in order to fit these quite specific needs.
if it's not too big a project (IOhannes must decide), i think that such an object (like [canvaserror]) would do no harm to "everyday users" and would at least be very handy for those who have a need for it.
On 6/14/21 10:37 AM, Peter P. wrote:
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
i think that would be *your* problem. if you want to catch error messages from two instances of the same objectclass, just put them into separate canvases. simple as that.
I think Peter's concern is valid and it's actually another reason why I wouldn't like such a design.
since it would be part of IEMGUTS (which i think is where it belongs to), people usually know what they let themselves in for and would design their patches accordingly. for example, there's no real need for more than one [soundfiler] or [text define] objects in a canvas...
Here's another idea, which I don't really love, but which I would prefer over your proposed [canvaserror]:
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".
sounds nice, too. but it wouldn't verbosely specify the type of error, like the console output, would it ?
just my 2c
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...