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