I'd perhaps emphasized a bit the use of Result over Either (and Maybe) so that we keep consistent with our other functions that are currently IO (Result a). This will also make easier to use ResultT later.
Otherwise LGTM, thanks (no need to resend). On Thu, Jan 23, 2014 at 1:53 PM, Klaus Aehlig <[email protected]> wrote: > While it is already standard in the Ganeti code base, explicitly > document that we do not like Exceptions and use sum types instead. > > Signed-off-by: Klaus Aehlig <[email protected]> > --- > doc/dev-codestyle.rst | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/doc/dev-codestyle.rst b/doc/dev-codestyle.rst > index 79261d5..56559d6 100644 > --- a/doc/dev-codestyle.rst > +++ b/doc/dev-codestyle.rst > @@ -476,6 +476,21 @@ complex expression; this usually means the expression > is too complex, however. > > Similarly, provide Haddock-style comments for top-level definitions. > > +Use sum types instead of exceptions > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +Exceptions make it hard to write functional code, as alternative > +control flows need to be considered and compiler support is limited. > +Therefore, Ganeti functions should never allow exceptions to escape. > +Function that can fail should report failure by returning an appropriate > +sum type (``Either`` or one of its glorified variants like ``Maybe`` or > +``Result``). > + > +As other Ganeti functions also follow these guide lines, they can safely > +be composed. However, be careful when using functions from other > libraries; > +if they can raise exceptions, catch them, preferably as close to their > +origin as reasonably possible. > + > Parentheses, point free style > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- > 1.8.5.3 > >
