edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Booz <scab...@gmail.com>
Subject Applications returning exceptions back to quarks runtime
Date Thu, 21 Jul 2016 18:47:47 GMT
I just joined this mailing list. I have been playing around with quarks
since yesterday. It's very interesting given the project I'm working on. I
think I'm starting to get the hang of the programming model. I forked and
built the master branch yesterday so I am on current code (except for the
renames that I was just reading about).

I am encountering a problem where one of my streams just stops. I know this
because I am calling print() on that stream before I submit.

My application has several streams that process data and pass it on to the
next stream, which also does some processing and then passes it on, etc. I
am using TWindow.batch() for this purpose. Here is my question; if the
lambda function that processes a window into a new stream encounters an
exception but DOES NOT handle it, what is supposed to happen? I would have
expected the quarks runtime to catch all exceptions from the apply
callbacks, but I don't think that's what's happening. I rewrote my lambda
function to catch exceptions, and once in a while the catch clause gets
control. I think it's because the thread which handles that stream is
getting control more quickly than data is put into it's stream. When I
catch and handle exceptions like this, the stream DOES NOT stop. It only
seems to stop when I remove the exception handling. Is this by design? Or
do you think the lambda functions MUST check for input before they attempt
to do anything?

It is very inconvenient (from a programming model perspective) for the
lambda functions to have to do exception handling in simple cases, but if
this is the designed programming model then at least I know how to handle


Dave Booz

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message