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!
--
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
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
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
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;
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;
>
>> 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
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
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:
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
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
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
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
> 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
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
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:
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
;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
> -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
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.
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
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
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.
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
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,
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
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
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
> -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:
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
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
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
32 matches
Mail list logo