06:53 <fr33domlover> isd: cool! great news for me ^_^

06:56 <fr33domlover> isd: is there a standard mechanism for exceptions in Cap'n Proto? I mean, if I leave multiple kinds of possible errors to be communicated via exception rather than the return type of a method, how do I catch and analyze the exception to know what exactly happened? Or should I reserve exceptions for those more fatal cases where program behavior

06:56 <fr33domlover> doesn't depend on the kind of error?

07:07 <isd> The capnp philosophy is that errors are more for "faults," yeah -- there's a fixed set of them, see Capnp.Rpc.Errors, or the Exception type defined in rpc.capnp

07:07 <isd> If you need structured information you generally want to use the return value

07:08 <isd> Inspecting exceptions is good for dealing with disconnects & version skew, but isn't designed for "application level" errors

07:14 <fr33domlover> Thanks for explaining :)

07:15 <fr33domlover> I finally got an approval for the funding, expecting an exciting year of forge federation work ^_^

07:15 <ocdtrekkie> Is the persistence helpers something that will make sense to implement in other capnp implementations in a common way?

07:16 <ocdtrekkie> Congratulations!

07:37 <isd> Jacob Weisz: the bits that are relevant at the protocol, definitely, though that's partially specified already; see persistent.capnp

07:38 <isd> But there's also just "put stuff in the library to make this not require as much boilerplate"

08:10 <isd> fr33domlover: also: while I can't promise any particular level of responsiveness, please do speak up about things in the API that are lacking; I've gotten relatively little feedback from users on haskell-capnp, so I assume the API has problems but I don't know what they all are. Open issues.