2013/6/25 Nikita Popov nikita@gmail.com:
but I'm against the generic catch{} statement.
I'm sharing Nikita's opinion, with the difference of a bit more
enthusiasm on leaving off the variable as it could make it more
obvious that there is no intention in using the variable, and that no
memory
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koeho...@gmail.com wrote:
Hi all,
I just published an RFC that proposes to add catch-statement without needing
to specify a variable, and support for fully anonymous catches.
Details can be found at:
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koeho...@gmail.comwrote:
Hi all,
I just published an RFC that proposes to add catch-statement without
needing to specify a variable, and support for fully anonymous catches.
Details can be found at:
On 25 June 2013 17:07, Nikita Popov nikita@gmail.com wrote:
No opinion on leaving off $e, but I'm against the generic catch{} statement.
I second the concerns about empty catch{}.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 25 June 2013 17:07, Nikita Popov nikita@gmail.com wrote:
No opinion on leaving off $e, but I'm against the generic catch{} statement.
I second the concerns about empty catch{}.
--
Regards,
Mike
As most of you seem to discard the idea about and empty catch (I can see why,
no
Hi all,
I just published an RFC that proposes to add catch-statement without needing to
specify a variable, and support for fully anonymous catches.
Details can be found at:
https://wiki.php.net/rfc/anonymous_catch
Regards,
Joost Koehoorn
--
PHP Internals - PHP Runtime Development Mailing
Joost,
First off, let me say welcome and thanks for the contribution!
I have a couple of questions around the intended proposal.
1. How do you plan on handling the case where there are multiple catch
blocks?
try {
code();
} catch {
doSomething();
} catch {
