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 had a case where I used something similar in Java code,
so I can tell when it's useful:
- You call some complex object that can fail for a lot of reasons (like
HTTP client talking to remote service)
- It can fail with a number of exceptions because something went bad -
i.e. network is bad, DNS is bad, server is down, service is too busy,
your request syntax is wrong, request is correct but you're not allowed
to execute it, etc.
- These causes can be roughly separated into two groups - requests that
we can and should repeat - e.g. "server too busy" situation, and those
that we should not repeat, e.g. "bad syntax" situation
- Furthermore, failures can be "soft" - fail this request but continue
next ones in the batch, or "hard" - drop everything and call for help
because something is seriously broken.

In this situation, grouping exceptions - which, due to being from
different layers of the complex object do not follow any single
structure - becomes very convenient. Of course it is possible to write a
long tree of copy-paste handlers for each of the three cases, but it's
annoying. Much cleaner to have just three branches. And of course I
don't want to do something like catch(Exception) because *shudder*...

> say, it's very likely they should be handled differenty anyway. Or 
> rather, very generically, which you can do with "catch (Exception $e)".

catch(Exception) is practically never a good idea, unless you really are
able to handle *every* exception. Now in PHP that includes parse errors,
type errors, etc. I don't think any random code - except for a very
generic final error handler - would ever want to do that.
-- 
Stas Malyshev
smalys...@gmail.com

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

Reply via email to