I sent the message below to the wrong list... Here we go again.
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@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list