Le ven. 22 avr. 2016 à 00:10, Dan Ackroyd <danack@basereality.com> a écrit :
> On 20 April 2016 at 23:16, Patrick ALLAERT <patrickallaert@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.
>
Your are absolutely right. I didn't meant one to modify libraries' or
someone else's code, just the part you are in control of and that one can
rely on Exception _interfaces_ rather than always use an Exception
hierarchy solely based on inheritance. Transforming Exceptions is also
rather common and doesn't require modifying external code.
> > 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.
>
Sorry if someone found my attitude inappropriate or offensive. I just
wanted to bring the attention that most of the Exception examples mentioned
in this thread seems like wrong usage for Exceptions.
There is just nothing more repeatable or common cases than "resource not
found", "method not allowed", "access denied",... They are all non
exceptional cases better handled without exceptions and with clean APIs
reflecting the business logic of the application.
e.g.:
if (!$actionAccessValidator->check($user, $resource, $action)) {
return false;
}
$action->run($resource);
return true;
Should be preferred over:
try {
// $action->run() combines here both access checking + the actual logic
$action->run($resource, $user);
}
catch (AccessDeniedException $e) {
return false;
}
return true;
I'm not going to mention the advantage of decoupled code.
My vote was mostly motivated by the absence of examples showing code that
is well written and designed which can benefit ot this new language
construct.
> 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.
>
Yes, but my worries are that it can only or mostly be used in cases where
the issues relies elsewhere, I would prefer to avoid giving a signal to
developers that make them comfortable using bad design practices.
Cheers,
Patrick
