Also, we don't optimize those away, it would not be sensible, because it's not sensible to deploy those catch blocks in the first place.
Cheers Joe On Fri, Feb 20, 2015 at 8:38 AM, Joe Watkins <pthre...@pthreads.org> wrote: > The custom exception must derive from AssertionException, so the same > optimization is possible. > > Cheers > Joe > > On Fri, Feb 20, 2015 at 8:28 AM, Xinchen Hui <larue...@php.net> wrote: > >> Hey: >> >> >> >> On Thu, Feb 19, 2015 at 5:09 PM, Joe Watkins <pthre...@pthreads.org> >> wrote: >> > Morning internals, >> > >> > The expectations RFC is now in voting phase: >> > https://wiki.php.net/rfc/expectations#vote >> >> sorry, the thread is too long to read.. I am not sure whether there >> was some similar opinion before.. >> >> I voted without custom exception, that is because. >> >> if all assertion exception is AssertException, then we can simply >> optimized them away while zend.assert is disabled.. >> >> like: >> >> try { >> foo(); >> bar(); >> assert(); >> } catch (AssertException $e) { >> //these statements can be optimized away. >> } >> >> but with custom exception.. >> >> try { >> >> sqllitefunc(); // no threw >> sqllitefunc1(); //no threw >> assert("", new SqlLiteException()); >> } catch (SqlliteException $e) { >> //we are not sure maybe sqllitefunc can throw SqliteException. >> // thus we can not optimized these statements ayway >> } >> >> thanks >> > >> > Cheers >> > Joe >> >> >> >> -- >> Xinchen Hui >> @Laruence >> http://www.laruence.com/ >> > >
