On 20 April 2016 at 23:16, Patrick ALLAERT <patrickalla...@php.net> wrote:
> It's also perfectly possible to make all those Exceptions implement a
> "MatchingFailedException" interface (even empty).
Apologies for continuing the conversation, even after the RFC is
incredibly likely to pass, but; I don't understand that argument at
all, and think I disagree with the philosophy behind it.
If it was followed, it would mean that exception classes would need to
be aware of how they are being used. When exception classes are
defined in a library, and the exceptions are being caught in an
applicaton, wouldn't adding applicaton specific interfaces to the
libaries exception classes just violate the separation between the
two? It doesn't seem to be good practice.
It would also lead to multiple interfaces being added to each
exception class. e.g. if in the application we had these catches in
different places in the application:
try {
return foo();
} catch (ResourceNotFoundException $e) {
return FALSE;
} catch (ParamNotConvertedException $e) {
return FALSE;
}
try {
return bar();
} catch (ResourceNotFoundException $e) {
return FALSE;
}
catch (AccessDeniedHttpException $e) {
return FALSE;
}
try {
return quux();
} catch (ResourceNotFoundException $e) {
return FALSE;
} catch (MethodNotAllowedException $e) {
return FALSE;
}
Where we specifically want to catch ResourceNotFoundException and one
other exception. If we followed your advice and added a specific
interface to the exceptions for each of the separate combinations, so
that we could catch just the interface we would end up with this:
class ResourceNotFoundException extends \Exception implements
FooExInterface, BarExInterface, QuuxExInterface {}
i.e. having to add one interface per usage. That doesn't seem that
great either....and again is altering a class based on how it's going
to be used.
> It encourages people to replace any kind of condition with an exception,
> leading to less readable code and incomplete API.
I don't think this is the right attitude to have when designing a
progrmming language.
Any feature that enables developers to write code that covers edge
cases in their application is by it's very nature going to be possibly
to use in a way most people consider inappropriate.
It's much more productive to focus on making code/features that are
useful when used sensibly. Worrying that people might use it in a way
that you wouldn't recommend using it, is fundamentally the wrong
problem to try to address when designing a language.
I think that's true in general but particularly true in a language
like PHP where one application might be programmed in a very different
way to another application. What would be useful and appropriate for
one of them would be could considered a horrendous hack* in another
application.
If we are limiting ourselves to adding features that are correct and
appropriate to use in all applications, that is limiting ourselves to
a subset of the features that people would want to have to cover all
of their use-cases.
cheers
Dan
Ack
* For example, a lot of people strongly dislike annotations. A
significant number of people use annotations in their applications.
Neither groups is 'right' or 'wrong', but it would be wrong for the
people who don't like annotations to say that annotations should never
be used.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
