New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Laravel 5 module disable exception handling #2763

Closed
janhenkgerritsen opened this Issue Feb 2, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@janhenkgerritsen
Contributor

janhenkgerritsen commented Feb 2, 2016

I got the idea from this screencast by Adam Wathan: http://adamwathan.me/2016/01/21/disabling-exception-handling.

Add two methods disableExceptionHandling and enableExceptionHandling to the module. Also makes this available through the module config.

I also think we can disable the exception handling by default, in most cases you will probably want to see the actual exception in your tests.

@janhenkgerritsen

This comment has been minimized.

Show comment
Hide comment
@janhenkgerritsen

janhenkgerritsen Feb 15, 2016

Contributor

Implemented in #2803.

Added two methods to the Laravel 5 module:

  • disableExceptionHandling
  • enableExceptionHandling

This functionality can also be configured through the module config with the disable_exception_handling variable.

The implementation was not as straightforward as expected, because not all exceptions should be intercepted. For example ValidationException and ModelNotFoundException are part of the normal application flow of a Laravel application.

The current implementation only disables exception handling for exceptions that could not be handled by the Laravel application itself.

Exception handling is now disabled by default.

Contributor

janhenkgerritsen commented Feb 15, 2016

Implemented in #2803.

Added two methods to the Laravel 5 module:

  • disableExceptionHandling
  • enableExceptionHandling

This functionality can also be configured through the module config with the disable_exception_handling variable.

The implementation was not as straightforward as expected, because not all exceptions should be intercepted. For example ValidationException and ModelNotFoundException are part of the normal application flow of a Laravel application.

The current implementation only disables exception handling for exceptions that could not be handled by the Laravel application itself.

Exception handling is now disabled by default.

@torkiljohnsen

This comment has been minimized.

Show comment
Hide comment
@torkiljohnsen

torkiljohnsen Mar 15, 2016

Contributor

@janhenkgerritsen Breaking change-much? After quite a bit of searching I now understand why my API suite is no longer returning 404 errors automatically… 😑

Contributor

torkiljohnsen commented Mar 15, 2016

@janhenkgerritsen Breaking change-much? After quite a bit of searching I now understand why my API suite is no longer returning 404 errors automatically… 😑

@janhenkgerritsen

This comment has been minimized.

Show comment
Hide comment
@janhenkgerritsen

janhenkgerritsen Mar 15, 2016

Contributor

Yeah I know, but we didn't want to wait with this feature for 2.2 because it is really nice for normal functional tests.

We could have released with this feature disabled by default, but at the end I decided that I wanted it enabled by default because it addresses a lot of the frustrations users had with the exception handling of their applications. And my thinking was that it is easy for the people that can not or do not want to use this feature to disable it through the module configuration.

The change was mentioned in the changelog, but I can understand your frustration if it took you some time to figure out what was going wrong.

Contributor

janhenkgerritsen commented Mar 15, 2016

Yeah I know, but we didn't want to wait with this feature for 2.2 because it is really nice for normal functional tests.

We could have released with this feature disabled by default, but at the end I decided that I wanted it enabled by default because it addresses a lot of the frustrations users had with the exception handling of their applications. And my thinking was that it is easy for the people that can not or do not want to use this feature to disable it through the module configuration.

The change was mentioned in the changelog, but I can understand your frustration if it took you some time to figure out what was going wrong.

@torkiljohnsen

This comment has been minimized.

Show comment
Hide comment
@torkiljohnsen

torkiljohnsen Mar 15, 2016

Contributor

No need to apologize. We appreciate your hard and diligent work on this! 👍

Contributor

torkiljohnsen commented Mar 15, 2016

No need to apologize. We appreciate your hard and diligent work on this! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment