Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-30 Thread Pascal MARTIN, AFUP
Le 17/04/2016 18:51, Bronisław Białek a écrit : We've opened the vote on https://wiki.php.net/rfc/multiple-catch Hi, At AFUP, we would be +1 on this RFC. Basically: small feature that should not break existing code and can be useful in some situations. Thanks for your work on this! --

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-30 Thread Björn Larsson
Den 2016-04-25 kl. 11:49, skrev Rowan Collins: Patrick ALLAERT wrote on 24/04/2016 14:18: There is just nothing more repeatable or common cases than "resource not found", "method not allowed", "access denied",... They are all non exceptional cases better handled without exceptions and with

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-25 Thread Rowan Collins
Patrick ALLAERT wrote on 24/04/2016 14:18: There is just nothing more repeatable or common cases than "resource not found", "method not allowed", "access denied",... They are all non exceptional cases better handled without exceptions and with clean APIs reflecting the business logic of the

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-24 Thread Patrick ALLAERT
Le ven. 22 avr. 2016 à 00:10, Dan Ackroyd a écrit : > On 20 April 2016 at 23:16, Patrick ALLAERT wrote: > > > It's also perfectly possible to make all those Exceptions implement a > > "MatchingFailedException" interface (even empty). > > Apologies

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-21 Thread Dan Ackroyd
On 20 April 2016 at 23:16, Patrick ALLAERT wrote: > It's also perfectly possible to make all those Exceptions implement a > "MatchingFailedException" interface (even empty). Apologies for continuing the conversation, even after the RFC is incredibly likely to pass, but;

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-20 Thread Patrick ALLAERT
Zeev, Le mar. 19 avr. 2016 à 11:56, Zeev Suraski a écrit : > In Drupal 8, many catch blocks simply resort to return FALSE or TRUE. For > example: > > try { > return $router->match($path); > } > catch (ResourceNotFoundException $e) { > return FALSE; >

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Levi Morrison
>> Except these two are in separate libraries that cannot share an interface. > > If these are separate libraries, you can't be sure that method does the > same thing, or even that it will be existing in both. This is not true. I can read the documentation for each method and know they are the

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Fleshgrinder
On 4/19/2016 9:39 PM, Stanislav Malyshev wrote: > Hi! > >> Except these two are in separate libraries that cannot share an interface. > > If these are separate libraries, you can't be sure that method does the > same thing, or even that it will be existing in both. > >> An interface is not

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Stanislav Malyshev
Hi! > Except these two are in separate libraries that cannot share an interface. If these are separate libraries, you can't be sure that method does the same thing, or even that it will be existing in both. > An interface is not possible: separate libraries. Duck-typing is not > appropriate:

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Bishop Bettini
On Tue, Apr 19, 2016 at 2:13 PM, Stanislav Malyshev wrote: > Hi! > > > namespace Application; > > function log(Eloquent\Collection | Haldayne\Map $entity) { > > $logger->log($entity->toArray()); > > } > > This is bad design. It assumes that two completely unrelated

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Stanislav Malyshev
Hi! > namespace Application; > function log(Eloquent\Collection | Haldayne\Map $entity) { > $logger->log($entity->toArray()); > } This is bad design. It assumes that two completely unrelated classes have the same function and it means the same. If it's indeed true, we have a way to express

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Dmitry Stogov
On 04/19/2016 04:09 PM, Levi Morrison wrote: On Tue, Apr 19, 2016 at 6:39 AM, Dmitry Stogov wrote: Only one note. I would prefer to use "," instead of "|" as a class name separator. Especially if "Union types" are not accepted. The rest should be fine. On the other hand if

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Bishop Bettini
On Mon, Apr 18, 2016 at 9:28 PM, Stanislav Malyshev wrote: > Hi! > > > It's about the perception of consistency. "Oh, I can do this! Neat:" > > > > function neat(Foo | Bar $a) { ... } > > You shouldn't be able to do this, because it makes no sense - why would > a function

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Zeev Suraski
> On 19 באפר׳ 2016, at 15:46, Dmitry Stogov wrote: > > Only one note. I would prefer to use "," instead of "|" as a class name > separator. > Especially if "Union types" are not accepted. > The rest should be fine. > +1 from me as well on that. We could have that change as

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Levi Morrison
On Tue, Apr 19, 2016 at 6:39 AM, Dmitry Stogov wrote: > Only one note. I would prefer to use "," instead of "|" as a class name > separator. > Especially if "Union types" are not accepted. > The rest should be fine. On the other hand if union types is accepted it makes no sense

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Dmitry Stogov
Only one note. I would prefer to use "," instead of "|" as a class name separator. Especially if "Union types" are not accepted. The rest should be fine. Thanks. Dmitry. From: Bronisław Białek Sent: Sunday, April 17, 2016 19:51 To:

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Ivan Enderlin
Hello, Representing the Hoa project community, we have voted yes. Not everyone was agree (60% yes, 40% no), but my vote reflects the average. Main argument in favor of no: * Encourage badly designed API. Main argument in favor of yes: * This is not an edge case when dealing with badly

RE: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Zeev Suraski
;internals@lists.php.net> > Subject: Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types > > On Mon, 18 Apr 2016, Marco Pivetta wrote: > > > Heya, > > > > I voted "NO" due to previous discussion. TL;DR: this is FAR off the > > 80/20 use-case for a

RE: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-19 Thread Zeev Suraski
> -Original Message- > From: Stanislav Malyshev [mailto:smalys...@gmail.com] > Sent: Tuesday, April 19, 2016 8:11 AM > To: Larry Garfield <la...@garfieldtech.com>; internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Stanislav Malyshev
Hi! > Admittedly Foo|Bar is of limited use, although there is some use. > Foo, however, has plenty of uses. That is a different topic, not related to exceptions at all. > I do agree with the sentiment that having Foo|Bar for catch but not for > function signatures is going to confuse people.

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Larry Garfield
On 04/18/2016 08:28 PM, Stanislav Malyshev wrote: Hi! It's about the perception of consistency. "Oh, I can do this! Neat:" function neat(Foo | Bar $a) { ... } You shouldn't be able to do this, because it makes no sense - why would a function accept two random types and only them? That's

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Stanislav Malyshev
Hi! > It's about the perception of consistency. "Oh, I can do this! Neat:" > > function neat(Foo | Bar $a) { ... } You shouldn't be able to do this, because it makes no sense - why would a function accept two random types and only them? That's probably a bad design - it should be one type or

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Bishop Bettini
On Mon, Apr 18, 2016 at 8:54 PM, Stanislav Malyshev wrote: > Hi! > > > catch constitutes a formal signature, exactly like a function signature. > In > > my mind, this proposal and the union types proposal are intrinsically > tied. > > If we have one, we must have the other.

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Stanislav Malyshev
Hi! > catch constitutes a formal signature, exactly like a function signature. In > my mind, this proposal and the union types proposal are intrinsically tied. > If we have one, we must have the other. If not, we're inducing a sadness. This has nothing to do with union types. It is just a

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Bishop Bettini
On Mon, Apr 18, 2016 at 9:40 AM, Marco Pivetta wrote: > > I voted "NO" due to previous discussion. TL;DR: this is FAR off the 80/20 > use-case for a language syntax change. > > ... > These 3 exceptions usually result in separate handling anyway. If same > handling is needed,

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Stanislav Malyshev
Hi! > Even this is a scary way to do it. As you don't know which exception > class you have, how would you know how to handle each separately. You'd > have to if ($caught instanceof InvalidArgumentException) etc to be sure > that what you're doing with the object is allowed. I just recently

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Dan Ackroyd
On 18 April 2016 at 16:17, Derick Rethans wrote: > If they are user defined exceptions, you should make them implement an > interface, Even within one oranisation, getting different teams to agree to common interfaces is not always possible. But when the exceptions are

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Derick Rethans
On Mon, 18 Apr 2016, Marco Pivetta wrote: > Heya, > > I voted "NO" due to previous discussion. TL;DR: this is FAR off the 80/20 > use-case for a language syntax change. I'm with you on this one. > C from my answer elsewhere: > > The following typical example is something REALLY rare, and

RE: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Zeev Suraski
> -Original Message- > From: Marco Pivetta [mailto:ocram...@gmail.com] > Sent: Monday, April 18, 2016 4:41 PM > To: Dan Ackroyd <dan...@basereality.com> > Cc: Bronisław Białek <afte...@gmail.com>; PHP internals > <internals@lists.php.net> > Subject:

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-18 Thread Marco Pivetta
Heya, I voted "NO" due to previous discussion. TL;DR: this is FAR off the 80/20 use-case for a language syntax change. C from my answer elsewhere: The following typical example is something REALLY rare, and requiring a parser change for it seems excessive: try { // ... } catch

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-17 Thread Dan Ackroyd
I voted yes. It's really not that common that I have to do stuff in exception handling, when I do need to do some clearing up, or checking to see if the operation that threw the exception needs to be re-tried, having to repeat that code in all of the catch statements that need it, is just nasty

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

2016-04-17 Thread Björn Larsson
Den 2016-04-17 kl. 18:51, skrev Bronisław Białek: Hi Internals, We've opened the vote on https://wiki.php.net/rfc/multiple-catch Voting will end on 2015-05-01 Very nice that you added "When is it usefull". Could also have added when is it not useful, but now we are in voting... This feature