Return to Answer

Exception handling in Drupal

Exceptions are handled by the default event subscriber DefaultExceptionSubscriber, unless there is a more specific one.

Core defines several of them, which are listed here: 14 uses of KernelEvents::EXCEPTION

There are more exception handlers, because some of them are only base classes with more than one subclass like HttpExceptionSubscriberBase and modules can implement their own event subscribers.

How default exceptions are handled

When you throw an exception in code

throw new \exception('ID ' . $id . ' not found in table xyz!');

the default exception handler returns a 500 http status code with this standard message:

The website encountered an unexpected error. Please try again later.

If you enable error reporting (admin/config/development/logging) you get a more verbose exception message displayed on screen:

The website encountered an unexpected error. Please try again later.

Exception: ID abc not found in table xyz! in Drupal\mymodule... (line 123 of modules/custom/mymodule/src/....php).

Conclusion

Now what you want to do depends on how much information you want to disclose to the public. Often if you don't find the data you are looking for a 404 exception is more meaningful than a 500 exception. If none of the core exception handling fits your purpose you can implement a custom exception subscriber:

Handle database connection exception via custom handler

Exception handling in Drupal

Exceptions are handled by FinalExceptionSubscriber, unless there is a more specific exception subscriber handling it before.

Core defines several of them, which are listed here: 27 uses of GetResponseForExceptionEvent

How default exceptions are handled

When you throw an exception in code

throw new \exception('ID ' . $id . ' not found in table xyz!');

the default exception handler returns a 500 http status code with this standard message:

The website encountered an unexpected error. Please try again later.

If you enable error reporting (admin/config/development/logging) you get a more verbose exception message displayed on screen:

The website encountered an unexpected error. Please try again later.

Exception: ID abc not found in table xyz! in Drupal\mymodule... (line 123 of modules/custom/mymodule/src/....php).

Conclusion

Now, what you want to do depends on how much information you want to disclose to the public. Often if you don't find the data you are looking for a 404 exception is more meaningful than a 500 exception. If none of the core exception handling fits your purpose you can implement a custom exception subscriber:

Handle database connection exception via custom handler

Exception handling in Drupal

Exceptions are handled by the event subscriber DefaultExceptionSubscriber unless there is a more specific one defined. You find examples for specific exception handlers in core

https://api.drupal.org/api/drupal/vendor%21symfony%21http-kernel%21KernelEvents.php/constant/constants/KernelEvents%3A%3AEXCEPTION/8.3.x

There are more exception handlers than listed here, because for example HttpExceptionSubscriberBase is only a base class for all http exception handlers.

Example for the default exception handling

When you throw an exception anywhere in your code

throw new \exception('ID ' . $id . ' not found in table xyz!');

the default exception handler returns a 500 http status code with this standard message:

The website encountered an unexpected error. Please try again later.

If you enable error reporting (admin/config/development/logging) you get the exception message displayed on screen:

The website encountered an unexpected error. Please try again later.

Exception: ID abc not found in table xyz! in Drupal\mymodule... (line 123 of modules/custom/mymodule/src/....php).

Conclusion

Now what you want to do depends on how much information you want to disclose to the public. Often if you don't find the data you are looking for a 404 exception is more meaningful than a 500 exception. If none of the core exception handling fits your purpose you can implement a custom exception subscriber:

Handle database connection exception via custom handler

Exception handling in Drupal

Exceptions are handled by the default event subscriber DefaultExceptionSubscriber, unless there is a more specific one.

Core defines several of them, which are listed here: 14 uses of KernelEvents::EXCEPTION

There are more exception handlers, because some of them are only base classes with more than one subclass like HttpExceptionSubscriberBase and modules can implement their own event subscribers.

How default exceptions are handled

When you throw an exception in code

throw new \exception('ID ' . $id . ' not found in table xyz!');

the default exception handler returns a 500 http status code with this standard message:

The website encountered an unexpected error. Please try again later.

If you enable error reporting (admin/config/development/logging) you get a more verbose exception message displayed on screen:

The website encountered an unexpected error. Please try again later.

Exception: ID abc not found in table xyz! in Drupal\mymodule... (line 123 of modules/custom/mymodule/src/....php).

Conclusion

Now what you want to do depends on how much information you want to disclose to the public. Often if you don't find the data you are looking for a 404 exception is more meaningful than a 500 exception. If none of the core exception handling fits your purpose you can implement a custom exception subscriber:

Handle database connection exception via custom handler

Exception handling in Drupal

Exceptions are handled by the event subscriber DefaultExceptionSubscriber unless there is a more specific one defined. You find examples for specific exception handlers in core

https://api.drupal.org/api/drupal/vendor%21symfony%21http-kernel%21KernelEvents.php/constant/constants/KernelEvents%3A%3AEXCEPTION/8.3.x

There are more exception handlers than listed here, because for example HttpExceptionSubscriberBase is only a base class for all http exception handlers.

Example for the default exception handling

When you throw an exception anywhere in your code

throw new \exception('ID ' . $id . ' not found in table xyz!');

the default exception handler returns a 500 http status code with this standard message:

The website encountered an unexpected error. Please try again later.

If you enable error reporting (admin/config/development/logging) you get the exception message displayed on screen:

The website encountered an unexpected error. Please try again later.

Exception: ID abc not found in table xyz! in Drupal\mymodule... (line 123 of modules/custom/mymodule/src/....php).

Conclusion

Now what you want to do depends on how much information you want to disclose to the public. Often if you don't find the data you are looking for a 404 exception is more meaningful than a 500 exception. If none of the core exception handling fits your purpose you can implement a custom exception subscriber.

Exception handling in Drupal

Exceptions are handled by the event subscriber DefaultExceptionSubscriber unless there is a more specific one defined. You find examples for specific exception handlers in core

https://api.drupal.org/api/drupal/vendor%21symfony%21http-kernel%21KernelEvents.php/constant/constants/KernelEvents%3A%3AEXCEPTION/8.3.x

There are more exception handlers than listed here, because for example HttpExceptionSubscriberBase is only a base class for all http exception handlers.

Example for the default exception handling

When you throw an exception anywhere in your code

throw new \exception('ID ' . $id . ' not found in table xyz!');

the default exception handler returns a 500 http status code with this standard message:

The website encountered an unexpected error. Please try again later.

If you enable error reporting (admin/config/development/logging) you get the exception message displayed on screen:

The website encountered an unexpected error. Please try again later.

Exception: ID abc not found in table xyz! in Drupal\mymodule... (line 123 of modules/custom/mymodule/src/....php).

Conclusion

Now what you want to do depends on how much information you want to disclose to the public. Often if you don't find the data you are looking for a 404 exception is more meaningful than a 500 exception. If none of the core exception handling fits your purpose you can implement a custom exception subscriber:

Handle database connection exception via custom handler