On Mon, Jun 24, 2013 at 7:49 PM, Joost Koehoorn <joost.koeho...@gmail.com>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 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm just going to weigh-in here with my two cents.
When I look at the facts objectively I don't see a reason to turn down this
proposal, but I also don't see much of a reason to accept it. My only fear
is that people will abuse anonymous catch blocks in situations where it
would have been better to just properly handle the Exception.
For example, if you're doing this in your code you're probably writing some
pretty bad code that's tough to debug...
try
{
$this->connectToServer();
} catch {
$this->retry(3);
}
Why are we throwing Exceptions if we only want to retry the connection in
the event that it failed? That would be more likely better handled by the
callee where the connection can be retired up to a timeout or number of
re-attempts until it fails permanently and then throws an Exception.
Exceptions should be like broken promises. If the promise the method or
function makes can't be kept it should throw an Exception to notify the
caller and the caller should decide how to proceed from there. If the
caller doesn't care that the promise could not be kept they probably have
very special circumstances to consider. So I can live with catch(Exception
$e) { /* ignore $e */ }, but that's my only objection. It's one purely from
a stand-point of promoting better code.
I understand a lot of other languages may allow this, but then again a lot
of other languages give you more room to shoot yourself in the foot than
PHP does.
I'm pretty neutral about this feature overall.
