http-interop / http-middleware

PSR-15 interfaces for HTTP Middleware
MIT License
73 stars 7 forks source link

Exception concept? #23

Closed dbu closed 7 years ago

dbu commented 8 years ago

(Sorry, i just keep opening issues as i notice things that i would like to clarify.)

The process method does not define any @throw. On server side, i would assume that ecxeptions will be domain/framework specific and thus a middleware to translate exceptions into HTTP error responses (e.g. 404) will be specific as well. But on client side, there can be exceptions like "DNS error" or "Timeout while connecting" that have no response associated. Until we have a PSR for http client itself, there are no standard exceptions for that however. So again, i feel like we should remove client side middleware from this PSR until things are ready for it.

And while we can not specify specific exceptions, the PSR should talk about exceptions in general. Is it acceptable that a middleware throws an exception? What should a server middleware do if it finds a request unacceptable? Probably its all domain/framework specific, but then the PSR should clearly state that.

shadowhand commented 8 years ago

I think it would be valuable to have @mtdowling comment on this, as a significant project that uses client middleware.

schnittstabil commented 7 years ago

Personally, I like to have some ExceptionMiddleware, which I'm able to share across multiple projects:

class ExceptionMiddleware implements ServerMiddlewareInterface
{
    public function process(ServerRequestInterface $request, DelegateInterface $delegate)
    {
        try {
            return $delegate->process($request)
        } catch(PDOException $e) {
            // log $e and send an email
            return new Response(500, …);
        } catch (Exception $e) {
            // just log $e
            return new Response(500, …);
        }
    }
}

Hence, I think it's not framework specific, it's domain specific. However, I don't think this should be formalized, i.e. I don't think it is useful to introduce some MiddlewareExceptionInterface or similar.

mindplay-dk commented 7 years ago

And while we can not specify specific exceptions, the PSR should talk about exceptions in general. Is it acceptable that a middleware throws an exception? What should a server middleware do if it finds a request unacceptable? Probably its all domain/framework specific, but then the PSR should clearly state that.

I think this is a question to be answered by someone implementing a middleware stack?

The answer is going to differ based on opinion.

For example, in mindplay/middleman, I deliberately have no error handling, which I view as being a separate concern, which should be handled by a dedicated error-handling facility (such as league/booboo) or by a middleware component, such as demonstrated by @schnittstabil above.

Some middleware stacks are closer to micro-frameworks and have error-handling and other features built-in.

This specification is for an interface, not for a middleware stack implementation - hence, I don't think it's within the scope of this specification to stipulate implementation details such as error-handling.

Of course, it wouldn't hurt to have a (brief) paragraph somewhere in the document stating that.

shadowhand commented 7 years ago

Since PSR-15 has changed scope and will no longer deal with client middleware, the original question is no longer relevant.

I agree with @mindplay-dk that exception handling is outside the scope of this proposal.