> On Dec 11, 2016, at 5:49 AM, Matthias Vallentin <[email protected]> wrote: > > In Bro, one way to represent represent errors would be as a record with > an optional error field. If the field is set, an error took place and > one can examine it. Either the function returns one of these explicitly, > or the runtime (i.e., the interpreter) populates one. > > Here's a strawman of what I mean: > > type result = record { > error: failure &optional; > value: any &optional; > }
That type of structure for error handling/propagation seems fine to me. (Don’t see the advantage of using exceptions instead). > Then, the runtime would allow for automatic chaining of asynchronous > functions returning instances of type result: > > function f(x: T) : result; > function g(y: U) : result; > > // Calls g iff f did not fail and return value unpacking succeeded. > local r = g(f(x)); I might prefer just doing the unpacking myself. Having separate/explicit checks for each individual return value would naturally occur over time anyway (e.g. when debugging, adding extra logging, improving error handling). How common do you expect async function chains to occur? Any specific examples in mind where auto-chaining is very helpful? Maybe it’s more of a nice-to-have feature than a requirement? - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
