Out of curiosity, what's an actual example of code where the execution flow of exceptions is significantly more surprising than the execution flow of a billion manual checks to avoid "Fatal error: Call to a member function foo() on a non-object"?
I've heard the vague claim that exceptions are confusing for years, but for the life of me I've never seen exception-handling code that looked more complex or confusing than code riddled with checks for magic return values. -- brion On Mon, Oct 7, 2013 at 11:20 AM, Erik Bernhardson < ebernhard...@wikimedia.org> wrote: > Within mediawiki there is a split between returning false/null and throwing > exceptions. There is also the Status class used by the wikitext parser(the > Status class is somewhat closely tied to the parser reducing reusability > though). essentially there are 3 kinds of error handling used within > mediaiki. > > We talked amongst the Flow team and agreed that we prefer false/null over > exceptions, mostly due to issues where exceptions can short-circuit the > expected execution path just about everywhere in a non-obvious manner(a big > enough issue that java uses checked exceptions, another world of pain). > During code review we spend a reasonable amount of time just ensuring that > functions that can return false/null are actually checked. > > Moving forward, the Flow team is considering using a php implementation > that follows the ideas of the haskell Maybe monad( > https://github.com/schmittjoh/php-option ). This is, in concept, rather > similar to the Status class the wikitext parser returns. We would like to > use this library as a way to more explicitly handle error situations and > reduce the occurrences of forgetting to check false/null. This particular > pattern is very common in Functional languages. > > I do believe this method of error handling is friendlier to programmers > memory, easier to code review, and more explicit about what happens in the > error condition. Are there any concerns with the Flow project moving > forward and utilizing this as our primary error handling mechanism rather > than returning false/null? > > Erik B. > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
