Makes sense, thanks for the insight.

Quoting Kenton Varda (2017-05-23 18:26:46)
>    Ah.
>    Two things:
>    1) If the stream is dropped without done() ever having been called, you
>    know at least that the data is incomplete.
>    2) Usually, I would recommend that the method you call to say "write
>    data to this stream" should not return until all data is written.
>    �  �  get @0 (filename :Text, stream :ByteStream);
>    �  �  # Writes the content of the given file to the given stream.
>    Returns once all data is written
>    �  �  # and stream.done() has completed successfully.
>    -Kenton
>
>    On Tue, May 23, 2017 at 12:56 PM, Ian Denhardt <[1][email protected]>
>    wrote:
>
>      I'm talking about reporting an error to the receiver of the data,
>      not
>      the caller of write().�  E.g. I have a capnp interface for a remote
>      filesystem, and I want to read data from a file. I pass the server a
>      ByteStream to use to send me the data. How does the server report an
>      error *to me*?
>      Quoting Kenton Varda (2017-05-23 11:42:44)
>      >�  �  Hi Ian,
>      >�  �  I'm not sure I understand. write() can throw an exception.
>      Does that
>      >�  �  not solve the problem?
>      >�  �  -Kenton
>      >�  �  On Mon, May 22, 2017 at 5:01 PM, Ian Denhardt
>      <[1][2][email protected]>
>      >�  �  wrote:
>      >
>      >�  �  �  Are there established best practices for handling errors
>      that occur
>      >�  �  �  with
>      >�  �  �  async/push style interfaces, such as sandstorm's
>      Util.ByteStream[1]?
>      >�  �  �  That interface doesn't seem to supply a way to report e.g.
>      an IO
>      >�  �  �  error
>      >�  �  �  that occurs while streaming, and since the call that
>      obtained the
>      >�  �  �  ByteStream has already completed, the error can't be
>      reported via
>      >�  �  �  the
>      >�  �  �  rpc protocol's exception mechanism.
>      >�  �  �  I suppose one could just add a method for reporting the
>      error. But I
>      >�  �  �  wanted to poll to see if there was any standard pattern
>      for this.
>      >�  �  �  [1]: [2][3]https://github.com/sandstorm-io/sandstorm/blob/
>      master/src/sa
>      >�  �  �  ndstorm/util.capnp#L69
>      >�  �  �  --
>      >�  �  �  You received this message because you are subscribed to
>      the Google
>      >�  �  �  Groups "Cap'n Proto" group.
>      >�  �  �  To unsubscribe from this group and stop receiving emails
>      from it,
>      >�  �  �  send an email to [3][4]capnproto+unsubscribe@
>      googlegroups.com.
>      >�  �  �  Visit this group at [4][5]https://groups.google.com/
>      group/capnproto.
>      >
>      > Verweise
>      >
>      >�  �  1. mailto:[6][email protected]
>      >�  �  2. [7]https://github.com/sandstorm-
>      io/sandstorm/blob/master/src/sandstorm/util.capnp#L69
>      >�  �  3. mailto:[8]capnproto%[email protected]
>      >�  �  4. [9]https://groups.google.com/group/capnproto
>
> Verweise
>
>    1. mailto:[email protected]
>    2. mailto:[email protected]
>    3. https://github.com/sandstorm-io/sandstorm/blob/master/src/sa
>    4. mailto:capnproto%[email protected]
>    5. https://groups.google.com/group/capnproto
>    6. mailto:[email protected]
>    7. 
> https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/util.capnp#L69
>    8. mailto:capnproto%[email protected]
>    9. https://groups.google.com/group/capnproto

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/group/capnproto.

Attachment: signature.asc
Description: signature

Reply via email to