Thanks John. I was indeed thinking to Maybe and the monad bindings, and LYAH, or http://book.realworldhaskell.org/read/error-handling.html
the problems is I cannot uses these links in isolation ( to a Non haskellers) because they mention Monads, Lazyness, Algebric types, all this vocabularies that side track a beginner, ( or a manager ;-) then all I want to show is the generic concept ( powerpoint level) of how a forest of (non core) case can be streamlined in one major case ( the good outcome) , and all the rest ( exceptions in a non technical sense) are catched by the maybe monad, without sidetracking the readability of the code . I saw this somewhere on the blogosphere, but cannot remember where.. this is management level, and this is even worse than beginners techies, because they derails very quickly when talking "details" -------------- Luc be.linkedin.com/in/luctaesch/ (http://be.linkedin.com/in/luctaesch/) Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig) Le vendredi 29 mars 2013 à 06:47, John Lato a écrit : > In FP, I think this sort of problem is generally handled via algebraic data > types rather than exceptions. In particular this directly addresses the > issue of "exceptions don't necessarily shout themselves out", since the > compiler warns you if you've missed a case. > > They sound mathy, but algebraic data types are actually a pretty simple > concept. I think the "Learn You a Haskell" explanation is decent: > http://learnyouahaskell.com/making-our-own-types-and-typeclasses > > Provided I understand the context properly, actually using exceptions for > this sort of issue would be extremely rare practice. > > > On Fri, Mar 29, 2013 at 12:21 AM, luc taesch <luc.tae...@gmail.com > (mailto:luc.tae...@gmail.com)> wrote: > > I was looking for some link introducing the way FP/ Haskell handles errors > > and Exceptions. > > > > This is for a non FP Guy, and ideally withought scaring them with Monads > > and category theory :-). > > > > for the background : > > > > the guy said : As I mentioned in another thread in banking (in particular) > > it is the exception processing that often dominates the functionality of a > > system - as the core concept is generally very straightforward. Developing > > for "exception handling" (not in a Java/C++ sense) is a tricky thing - as > > the exception don't necessarily shout themselves out - and are often why we > > have large misunderstood legacy systems which are hard to replace. > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) > > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
