How to indicate an error from simpleHandler?

[brefphp]

How to indicate an error from simpleHandler?

[mnapoli]

Hey happy to see you try this out ^^

That's actually a very good point 🤔 I've focused on http and cli and I didn't think too much about that.

I was going to say you could throw an exception, but Bref's PHP part will not catch it so the lambda (the JS handler) will consider that as a PHP error. The lambda will return an error, not something useful though:

https://github.com/mnapoli/bref/blob/master/template/handler.js#L60

What Bref could do is catch exceptions and return the message of that exception to handler.js, that way the result of the lambda is marked as errored and the message will be the one of the PHP exception, WDYT?

However if you have more specific needs (returning additional data from the error) I guess you'll need to return data manually in the JSON.

Also be aware that by default, when a lambda fails, it is retried 3 times. For my prettyci jobs I disabled that. Also I directly update the GitHub status and call my API to report the build result, I don't have anything waiting for the lambdas/workers result.

[ondrejmirtes]

that way the result of the lambda is marked as errored and the message will be the one of the PHP exception, WDYT?

Yeah, it would be nice, but I need to differentiate between "expected exceptions" and "unexpected exceptions" - if something fails hard, I want to log it (via a top level error handler, for example registered by Sentry/Raven) and return a general error message like "An error occured." This could be compared to a general "HTTP 500" error in traditional web apps. In this case I don't want to propagate the exception error message because it might not be useful for the user.

But I also want to return expected errors - when user does something that blocks the request from being handled, but I expect this, like a parse error in the passed code example. This might be compared to "HTTP 422".

Usually MVC frameworks solve this by special handling of "ResponseException" and they propagate the error message to the response body itself. Any other exception that's not subtype of "ResponseException" is handled as a general error and results in "HTTP 500". Of course the naming is up to you 😊

But I think it would be useful if Bref did something similar.

[ondrejmirtes]

The expected "ResponseException" also does not get rethrown to the top error handler, but any other exception does.

[mnapoli]

In v0.3 errors/exceptions are caught by the runtime and a reported to AWS Lambda as an invocation error. This error contains the message of the exception (and the class name and stack trace).

Does that sound good?

If you want any other behavior to happen (e.g. avoid reporting internal exceptions to the caller) then you will need to wrap your code in a try/catch and rethrow a generic exception.

To me it makes sense.

[ondrejmirtes]

Yes, it’s okay 😊

On Sat, 5 Jan 2019 at 22:31, Matthieu Napoli ***@***.***> wrote: In v0.3 errors/exceptions are caught by the runtime and a reported to AWS Lambda as an invocation error. This error contains the message of the exception (and the class name and stack trace). Does that sound good? If you want any other behavior to happen (e.g. avoid reporting internal exceptions to the caller) then you will need to wrap your code in a try/catch and rethrow a generic exception. To me it makes sense. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#87 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGZuEbRAdi_uKUVo2qt-uaRf-wUEjGZks5vARm-gaJpZM4YZb2O> .

-- Ondřej Mirtes