Re: Announcing RFC 'Anonymous Catches'

From: Date: Mon, 24 Jun 2013 23:49:22 +0000
Subject: Re: Announcing RFC 'Anonymous Catches'
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On 25 juni 2013 at 01:20:04, Anthony Ferrara ([email protected]) 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 {
        code();
    } catch {
        doSomething();
    } catch {
        doSomethingElse();
    }
As mentioned as latest sentence in the Proposal chapter, an anonymous catch can only be used as the
latest catch, and there can only be one of them. This is also how my current implementation works.

2. You mention as a benefit "Better possibilities for static analysis tools". Can you
elaborate on this? I don't see how this sort of a change would have any effect (as catch would
be the same as the existing catch (\Exception $e))...
It's mostly for finding unused variables. I suppose that static analysers currently ignore
unused exception variables, but they don't have to when this is accepted and can properly
indicate unused exception variables.

3. What benefit short of not having to type (\Exception $e) would this have? Populating
the symbol table is extremely cheap at this stage, because the variable is already compiled in (so
no hash table lookup or anything).
Performance wise it's indeed very minor and doesn't really matter. It's more that
you're adding code indicating that only a specific exception is used, while that may not really
be the case.

Consider Java people --Java has Throwable as the superclass of Exception-- they may not know that in
PHP 'Exception' is the least-specific type and therefore used as catch-all.

As for leaving of the variable, the type of an exception mostly tells enough about what happened
(well, it should), so you don't have to inspect the exception's error code/message and
thus don't need the exception object at all.

Additionally, I would recommend changing the version target to 5.NEXT (which would be 5.6 in
practice).
Done!



As far as my personal feelings, I'd like to get some other commentary first.


Thanks again!!!

Anthony


Thread (10 messages)

« previous php.internals (#67788) next »