I started replying, but there are just way too many different opinions to reply to you all. IF the accepted method of handling errors in mediawiki is to throw an exception and cancel page render we will simply do that instead.
On Mon, Oct 7, 2013 at 2:09 PM, Brion Vibber <bvib...@wikimedia.org> wrote: > So I took a quick look at https://github.com/schmittjoh/php-option -- it > appears to be a wrapper object around queries that can throw an exception > for you if the wrapped value is null (exactly like just using exceptions in > the first place), or can check for nullness and replace it with an > alternate value (equivalent to an if/then or try/catch block, just in a > function call instead of a block construct). > > At best, it's syntactic sugar and adds no expressiveness to the language. > At worst, it complicates the codebase by adding another coding pattern that > would be different from the rest of the codebase. I don't think this would > be a particularly useful pattern to follow. > > -- brion > > > > On Mon, Oct 7, 2013 at 12:45 PM, Brion Vibber <bvib...@wikimedia.org> > wrote: > > > 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 > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
