[PD-dev] [PD] Ability to access error messages from patch

Christof Ressi info at christofressi.com
Mon Jun 14 13:58:29 CEST 2021


> 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.

> 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.

---

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".

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.

Christof

On 14.06.2021 13:29, IOhannes m zmoelnig wrote:
> On 6/14/21 10:23 AM, Roman Haefeli wrote:
>> On Mon, 2021-06-14 at 10:02 +0200, Peter P. wrote:
>>
>>>   I am wondering how one would
>>> parse these error messages if they came from one single object outlet
>>> to
>>> tell where the error originated from?
>>
>> I am wondering about that, too. Maybe a [pderror] would be canvas-local
>> and only report errors from objects belonging to the local canvas? And
>> it would prepend the name of the object to the message?
>
> i quite like the idea of having a canvas-scope for such an object.
>
> however, i think [pderror] is a bad name, as i would expect this 
> object to be usable for *generating* errors (ala [print]), rather than 
> outputting them.
>
> anyhow, i think the proposal maps nicely to what other languages offer 
> as "exception handling".
> from that pov, a good name would be [catch] (which would be *very* 
> good, if, alas! that weren't already occupied by the similarly named 
> but totally different [catch~]), or [except] (but i somehow have the 
> feeling that this would need some explicit *connection* to the object 
> that is bailing out).
>
> with iemgut's in mind, i would go for [canvaserror] (or, for a more 
> general case: [canvasconsole]).
>
> 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.
>
> e.g. cf the python code
> ```
> try:
>   x=int("foo")
>   y=int("bar")
> except:
>   print("one of the two conversions failed")
> ```
>
>
> while thinking about the exception analogy, it might be interesting to 
> be able to re-throw an error message:
> if you don't want to hande the error in your canvas, you can just pass 
> it on to the parent canvas by sending it to an [error] object.
>
> the same could apply to [print], which can be considered just as a 
> "low-priority error".
>
> fgmdsr
> IOhannes
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20210614/6557233b/attachment.htm>


More information about the Pd-dev mailing list