Error & Exception Handling in Expressive

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Error & Exception Handling in Expressive

jpabbott
Hi,

Firstly I hope this is the right list for Zend Expressive questions.
Apologies if it isn't.

I've been looking into effective techniques for handling exceptions and
errors in Expressive. This is in the context of an API where I want to
return HTTP error codes to the client when something goes wrong, and also
perform various logging in the background. Pretty standard stuff.

To do this I've experimented with invoking post-route middleware from
within each catch block, but there doesn't seem to be a simple way to pass
the exception object from the catch block to the middleware. I've had
better results by extending the Zend\Stratigility\FinalHandler and invoking
my version from the catch block instead. This works well because the
exception can be passed to the handler via $next().

I was just wondering why the existing Zend\Stratigility\FinalHandler has so
many of its methods declared private though? It seems to me that extending
its behaviour is a valid use case and works well as a means to customise
error handling. But looking at the method signatures you wouldn't think it
was encouraged.

Is there a better/recommended way to handle errors with Expressive?

Incidentally, I have created a 'crash handler' service which deals with
uncaught errors and exceptions, and my custom finalhandler also hands
anything it catches over to the same service. This seems to work really
well but I'm open to adopting a different approach if need be.

Thanks,
- James
Reply | Threaded
Open this post in threaded view
|

Re: Error & Exception Handling in Expressive

Marco Pivetta
Heya,


On 21 January 2016 at 11:28, James Abbott <[hidden email]> wrote:

> I was just wondering why the existing Zend\Stratigility\FinalHandler has so
> many of its methods declared private though? It seems to me that extending
> its behaviour is a valid use case and works well as a means to customise
> error handling. But looking at the method signatures you wouldn't think it
> was encouraged.
>

Inheritance is not the right way to add "your own flavor" to an existing
behavior. The final handler is just a `function ($request, $response,
$error = null);` callable: implementing your own is the way to go ;-)

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Reply | Threaded
Open this post in threaded view
|

Re: Error & Exception Handling in Expressive

jpabbott
Hi Marco,

Thanks for your response. Good to know that the final handler is the right
way to go.

I'm not clear on why inheritance would be an invalid solution in this case
though. Isn't it specifically intended for extending the functionality of a
class in a scenario like this (where one class is a definite subtype of
another and you want to reuse some of the parent classes' functionality)?
Alternatively composition via an error handler interface in place of the
handleErrors() method could be used. Both would provide more flexibility
than locking down the whole class with private methods.

Cheers,
- James


On 21 January 2016 at 11:37, Marco Pivetta <[hidden email]> wrote:

> Heya,
>
>
> On 21 January 2016 at 11:28, James Abbott <[hidden email]> wrote:
>
>> I was just wondering why the existing Zend\Stratigility\FinalHandler has
>> so
>> many of its methods declared private though? It seems to me that extending
>> its behaviour is a valid use case and works well as a means to customise
>> error handling. But looking at the method signatures you wouldn't think it
>> was encouraged.
>>
>
> Inheritance is not the right way to add "your own flavor" to an existing
> behavior. The final handler is just a `function ($request, $response,
> $error = null);` callable: implementing your own is the way to go ;-)
>
> Cheers,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Error & Exception Handling in Expressive

Marco Pivetta
On 24 January 2016 at 12:41, James Abbott <[hidden email]> wrote:

> Hi Marco,
>
> Thanks for your response. Good to know that the final handler is the right
> way to go.
>
> I'm not clear on why inheritance would be an invalid solution in this case
> though. Isn't it specifically intended for extending the functionality of a
> class in a scenario like this (where one class is a definite subtype of
> another and you want to reuse some of the parent classes' functionality)?
>

That's a misconception of how `extends` is used: inheritance is a mean to
express different sub-concepts, not really a code-reuse mechanism.


> Alternatively composition via an error handler interface in place of the
> handleErrors() method could be used. Both would provide more flexibility
> than locking down the whole class with private methods.
>

The class can really just be copied into your namespace and adapted to your
needs: It is ~300LOC, mostly comments tho (much lower CLOC).

It can be split into multiple collaborators (each of them being one of the
private methods, pretty much), but the benefits for the framework per-se
are minimal. I suggest simply moving it into your codebase as a first
attempt, and abstract only when there is solid ground for doing so.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Reply | Threaded
Open this post in threaded view
|

Re: Error & Exception Handling in Expressive

jpabbott
Thanks, I've taken a copy and started adapting it. The old inheritance debate could drag on so I'll leave it that :) Loving expressive!
- James

> On 24 Jan 2016, at 16:23, Marco Pivetta <[hidden email]> wrote:
>
>> On 24 January 2016 at 12:41, James Abbott <[hidden email]> wrote:
>> Hi Marco,
>>
>> Thanks for your response. Good to know that the final handler is the right way to go.
>>
>> I'm not clear on why inheritance would be an invalid solution in this case though. Isn't it specifically intended for extending the functionality of a class in a scenario like this (where one class is a definite subtype of another and you want to reuse some of the parent classes' functionality)?
>
> That's a misconception of how `extends` is used: inheritance is a mean to express different sub-concepts, not really a code-reuse mechanism.
>  
>> Alternatively composition via an error handler interface in place of the handleErrors() method could be used. Both would provide more flexibility than locking down the whole class with private methods.
>
> The class can really just be copied into your namespace and adapted to your needs: It is ~300LOC, mostly comments tho (much lower CLOC).
>
> It can be split into multiple collaborators (each of them being one of the private methods, pretty much), but the benefits for the framework per-se are minimal. I suggest simply moving it into your codebase as a first attempt, and abstract only when there is solid ground for doing so.
>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius     
>
> http://ocramius.github.com/
>