On 18 April 2016 at 16:17, Derick Rethans <der...@php.net> 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
originating in code that people don't have any control over (e.g.
anything open source) then changing the exceptions to match your
particular interface requirements is a completely impossible.
For example will you and Marco start taking requests to add particular
interfaces to any exceptions thrown by the code in the libraries you
maintain?
Derick wrote:
> As you don't know which exception
> class you have, how would you know how to handle each separately.
Why do you think you need to know how to handle each separately? If
you ever need to do something different based on the type of
exception, you probably wouldn't be using the multiple-catch. The
multiple-catch is almost only ever going to be used when you have a
list of exceptions where you're going to be doing the same thing for
each. e.g. for retrying an operation:
$success = false;
while ($attempts < 4) {
try {
foo();
$success = true;
}
catch (NetworkException | DBDeadLockException $e) {
// Save exceptions to add to surpressed exception
// when that RFC is hopefully passed.
$attempts++;
}
// All other
}
//Check for success or run out of attempts here.
For NetworkException and DBDeadLockException we're always going to do
the same thing; retry the operation a couple of times. For any
exception type where we would want to do something different......we'd
just use a separate catch block.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
