On Wed, Jun 26, 2013 at 7:54 AM, Joost Koehoorn wrote:
> On 26 juni 2013 at 08:35:59, Michael Wallner (m...@php.net) wrote:
> On 25 June 2013 22:23, Johannes Schlüter wrote:
> > On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote:
> >> Hi!
> >>
> >> > If I'm to understand this RFC correctly, i
On 26 juni 2013 at 08:35:59, Michael Wallner (m...@php.net) wrote:
On 25 June 2013 22:23, Johannes Schlüter wrote:
> On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote:
>> Hi!
>>
>> > If I'm to understand this RFC correctly, it is nothing more than a
>> > random suggestion someone posed i
>> If you have an exception like `BadCredentialsException` and throw it
>> during authentication if the user has entered wrong login data, than
>> you have such a situation right?
>> But do you need any further information? No - in the catch block it may
>> be enough to create a message for the
On Wed, Jun 26, 2013 at 8:31 AM, Christian Stoller wrote:
>>> But I think it looks a bit cleaner if the variable could be omitted,
>>> if it's not needed ;-)
>>
>> I don't think we need to change the language because Netbeans can't
>> figure out how catch blocks work.
>
> The Netbeans thing was ju
On 25 June 2013 22:23, Johannes Schlüter wrote:
> On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote:
>> Hi!
>>
>> > If I'm to understand this RFC correctly, it is nothing more than a
>> > random suggestion someone posed in the form of a tweet and the author is
>> > saying why not add it since
>> But I think it looks a bit cleaner if the variable could be omitted,
>> if it's not needed ;-)
>
> I don't think we need to change the language because Netbeans can't
> figure out how catch blocks work.
The Netbeans thing was just an example/addition.
> It's not used by you - which btw is usua
On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote:
> Hi!
>
> > If I'm to understand this RFC correctly, it is nothing more than a
> > random suggestion someone posed in the form of a tweet and the author is
> > saying why not add it since it's not hard to implement. So in summation
>
> Well,
On Tue, Jun 25, 2013 at 4:14 PM, Joost Koehoorn wrote:
> On 25 juni 2013 at 22:06:40, Sherif Ramadan (theanomaly...@gmail.com)
> wrote:
>
>
> So this entire discussion can be summed up nicely with "Let's make the
> variable optional because... why not?".
> Correct. The tweet was actually a serious
Hi!
> If I'm to understand this RFC correctly, it is nothing more than a
> random suggestion someone posed in the form of a tweet and the author is
> saying why not add it since it's not hard to implement. So in summation
Well, here we go - this is why not add it, because it makes working with
su
On 25 juni 2013 at 22:06:40, Sherif Ramadan (theanomaly...@gmail.com) wrote:
On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev wrote:
Hi!
> IMO actually it *makes* the code clearer, because $ignoredException is
> not used, though a variable name like $ignored is self-explanatory,
> too.
It's not
On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev wrote:
> Hi!
>
> > IMO actually it *makes* the code clearer, because $ignoredException is
> > not used, though a variable name like $ignored is self-explanatory,
> > too.
>
> It's not used by you - which btw is usually not a good idea - if you've
> go
Regarding all of the discussion about the unused variable:
If your catch blocks are too long or too complicated to be able to tell
that the variable is unused, then I highly suggest you refactor that
section.
---
To me, the only maybe-useful portion of this discussion would be the empty
catch wh
Hi!
> IMO actually it *makes* the code clearer, because $ignoredException is
> not used, though a variable name like $ignored is self-explanatory,
> too.
It's not used by you - which btw is usually not a good idea - if you've
got an exception, you usually should somehow react to it - at least log
On 25 June 2013 20:17, Stas Malyshev wrote:
> Hi!
> I don't think we need to change the language because Netbeans can't
> figure out how catch blocks work. This change doesn't provide any
> functionality that wasn't available before it, and does not make the
> code clearer - on the contrary, IMO
Hi!
> In such a case you do not need any `$e`variable. Netbeans for example
> always highlight's these variables because it is not used anywhere.
> But I think it looks a bit cleaner if the variable could be omitted,
> if it's not needed ;-)
I don't think we need to change the language because Ne
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
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:
>
> https://wiki.php.net/rfc/anonymous_catch
>
I, too, believes that omitting the exception variable is great.
In addition, anonymous catch blocks will shorten the code of "catch
(Exception $e)" so... is just a simpler way of writing - and that's what
PHP agenda aiming for, doesn't it? be a friendly and readable language.
Reading
try {
$fo
> 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
>
Hi.
I am not sure
Hi,
Another two cents here.
* Skipping binding a parameter to the exception would make debugging
harder. When you're stepping through code that isn't working correctly to
find a problem and then it throws an Exception which is caught in catch
block that doesn't name it e.g.
try
{
$connectio
On Mon, Jun 24, 2013 at 7:49 PM, Joost Koehoorn wrote:
> On 25 juni 2013 at 01:20:04, Anthony Ferrara (ircmax...@gmail.com) wrote:
> 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 ha
On 25 juni 2013 at 01:20:04, Anthony Ferrara (ircmax...@gmail.com) wrote:
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 {
21 matches
Mail list logo