[PD] Ability to access error messages from patch

[Christof Ressi]

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
>>
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at 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=