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
1) reset the global (per instance) error state to a reserved value
2) 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.
3) 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=8gelwsvceCfl8S54qwd_2K-7Ux1KXfqZmtASQ37VoS0&s=wIaD2xQChyOMZtLEyKYCnIgKliS1TuNuk-shjiuaJGY&e=
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
