Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What prevented me from using Playframework and going with Lift: 1. Play 1.0 (2.0 too?) used exceptions for flow control. I don't think this works for high traffic web sites. 2. Lift's CSS selector templating is slick, I would not like to go back to PHP/JSP/... style templating.

Very nice website.

[update: 2.0 has no more exception work flow]



2.0 doesn't use exceptions for flow control - but out of interest, what do you mean "I don't think this works for high traffic web sites"? 1 exception for a request won't affect performance, right?


Although exceptions have become faster, and you can speed them up (overwrite stack generation code), they are slow mostly due to filling the stack trace. Mostly based on this:

http://www.javaspecialists.eu/archive/Issue187.html


That article mentions that the performance is dependent on the fillInStackTrace() method, which play framework overrides to do nothing.


Was not familiar with this method, appreciate the heads up guys. Did some quick micro benchmarks and it looks like I got an 11.5x speedup in some code that was using Exceptions for flow control.


A small nitpick: Lift does (typically) use exceptions for control flow, for redirects.


Where did you find the reference to no more exception work flow? That seemed to be everywhere in the framework.


From the source code... the controller actions are all returning values: https://github.com/playframework/Play20/blob/master/samples/...


"Yes no more exception for flow control." via Twitter.


'grep -R throw .'

or you could just look at controller code...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: