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&P from my answer elsewhere:
> 
> The following typical example is something REALLY rare, and requiring a
> parser change for it seems excessive:
> 
>     try {
>         // ...
>     } catch (InvalidArgumentException $e) {
>         // same handling
>     } catch (PDOException $e) {
>         // same handling
>     } catch (BadMethodCallException $e) {
>         // same handling
>     }
> 
> These 3 exceptions usually result in separate handling anyway. If same
> handling is needed, you can as usual extract a private method  (if you are
> in a class) and deal with it there:
> 
>     try {
>         // ...
>     } catch (InvalidArgumentException $e) {
>         $this->sameHandling($e);
>     } catch (PDOException $e) {
>         $this->sameHandling($e);
>     } catch (BadMethodCallException $e) {
>         $this->sameHandling($e);
>     }
> 
>     private function sameHandling(Throwable $caught)
>     {
>         // same handling
>     }

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.

If they are user defined exceptions, you should make them implement an 
interface, and do a "catch (IMyException $e)" to be sure you can handle 
the different exceptions in a consistent manor. And that already works.

If they are exception classes defined by other libraries, then, as you 
say, it's very likely they should be handled differenty anyway. Or 
rather, very generically, which you can do with "catch (Exception $e)".

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to