Skip to content

Commit

Permalink
fix: Show Error View for RPC calls by default (vaadin#3002)
Browse files Browse the repository at this point in the history
* fix: Remove "enableErrorHandlerRedirect" parameter as now the feature is available by default

* First pass at editing.

* Second pass at editing.

* Third pass editing.

---------

Co-authored-by: russelljtdyer <[email protected]>
  • Loading branch information
mshabarov and russelljtdyer authored Dec 1, 2023
1 parent d20f352 commit 28c492a
Show file tree
Hide file tree
Showing 2 changed files with 15 additions and 23 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ order: 145

= Custom Error Handling

You can customize the error views related to navigation between different routes, as described in the <<{articles}/routing/exceptions#, Router Exception Handling>> documentation page.
You can customize the error views related to navigation between different routes. The handling of router exceptions is described on the <<{articles}/routing/exceptions#, Router Exception Handling>> documentation page.

For other unhandled runtime exceptions, an [classname]`ErrorHandler` class can be used to let users know that something went wrong. To do so, first create a custom [classname]`ErrorHandler` class. Then use that class to override the default error handler.

Expand Down Expand Up @@ -41,9 +41,9 @@ VaadinSession.getCurrent().setErrorHandler(new CustomErrorHandler());

To apply the custom error handler to all user sessions, you can use a [classname]`SessionInitListener`, which receives an event each time a new [classname]`VaadinSession` is initialized. See the <<session-and-ui-init-listener#,Session and UI Listeners>> documentation page to learn how to create a [classname]`SessionInitListener`.

[classname]`ErrorEvent` has method [methodname]`getComponent()` to get the handled [classname]`Component`, and the [methodname]`getElement()` method to get the handled [classname]`Element` when the error is thrown if available.
[classname]`ErrorEvent` has the method [methodname]`getComponent()` to get the handled [classname]`Component`, and the [methodname]`getElement()` method to get the handled [classname]`Element` when the error is thrown, if available.

For example, the following button click listener would have [classname]`ErrorEvent` [methodname]`getComponent()` return the clicked button:
For example, the following button-click listener has [classname]`ErrorEvent` [methodname]`getComponent()` return the clicked button:

[source,java]
----
Expand All @@ -52,10 +52,11 @@ Button button = new Button("Click me", event -> {
});
----


[role="since:com.vaadin:[email protected]"]
== Show Error Parameter Views for Non-Navigation Exceptions
== Error Parameter Views for Non-Navigation Exceptions

In the [classname]`DefaultErrorHandler`, it's possible to enable transitioning to an [interfacename]`HasErrorParameter<T extends Exception>` error view on exceptions. This is done by setting the `enableErrorHandlerRedirect` parameter to `true`. See <<{articles}/routing/exceptions#, Error Resolving>> for more information on the [interfacename]`HasErrorParameter`.
In the [classname]`DefaultErrorHandler`, it's possible to enable transitioning to an [interfacename]`HasErrorParameter<T extends Exception>` error view on exceptions. See the <<{articles}/routing/exceptions#, Error Resolving>> page for more information on the [interfacename]`HasErrorParameter`.

For a customized error handler, the same can be done by using the [classname]`ErrorHandlerUtil` method, [methodname]`handleErrorByRedirectingToErrorView` like so:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ description: Exception handling by the Router class.

[classname]`Router` provides special support for navigation target exceptions. When an unhandled exception is thrown during navigation, an error view is shown.

Exception targets work in the same way as regular navigation targets, but they don't typically have a specific `@Route` because they're shown for arbitrary URLs.
Exception targets work the same way as regular navigation targets, but they don't typically have a specific `@Route` because they're shown for arbitrary URLs.


== Error Resolving
Expand Down Expand Up @@ -37,22 +37,18 @@ public class RouteNotFoundError extends Component
}
----

This returns a `404` HTTP response and displays the text specified in the parameter to [methodname]`setText()`.

Exceptions are matched first by exception cause, then by exception super type.
This returns a `404` HTTP response and displays the text specified in the parameter to [methodname]`setText()`. Exceptions are matched first by an exception cause, then by an exception super type.

The `404` [classname]`RouteNotFoundError` for [classname]`NotFoundException`, and `500` [classname]`InternalServerError` for [classname]`java.lang.Exception` are implemented by default.

Also by default, the initial request first loads the client-side bootstrapping with an HTTP 200 response. An error page is rendered later in another request which returns an initial JSON data fragment, including the error page. The HTTP 404 response from [classname]`RouteNotFoundError` is only processed on the server side. It isn't returned to the browser as an HTTP code of the response.
Also by default, the initial request loads first the client-side bootstrapping with an HTTP 200 response. An error page is rendered later in another request, which returns an initial JSON data fragment, including the error page. The HTTP 404 response from [classname]`RouteNotFoundError` is only processed on the server side. It isn't returned to the browser as an HTTP code of the response.

If you enable the <<{articles}/configuration/properties/#properties,`eagerServerLoad` property>>, the initial JSON data fragment is part of the first request's response. It includes the [classname]`RouteNotFoundError` page with an HTTP 404 response.


== Custom Exception Handlers

You can override the default exception handlers by extending them.

The example here shows a custom "route not found" handler that uses a custom application layout:
You can override the default exception handlers by extending them. The example here shows a custom "route not found" handler that uses a custom application layout:

[source,java]
----
Expand All @@ -70,15 +66,9 @@ public class CustomNotFoundTarget
}
----

[NOTE]
Only extending instances are allowed. Exception targets may define [classname]`ParentLayouts`. [classname]`BeforeNavigationEvent` and [classname]`AfterNavigationEvent` are still sent, as in normal navigation. One exception may only have one exception handler.


=== Advanced Exception Handling Example

The following example assumes an application `Dashboard` that collects and shows widgets to users. Only authenticated users are allowed to see protected widgets.

If the collection instantiates a [classname]`ProtectedWidget` in error, the widget itself checks authentication on creation and throws an [classname]`CustomAccessDeniedException`.
The following example assumes an application `Dashboard` that collects and shows widgets to users. Only authenticated users are allowed to see protected widgets. If the collection instantiates a [classname]`ProtectedWidget` in error, the widget itself checks authentication on creation and throws an [classname]`CustomAccessDeniedException.`

The unhandled exception propagates during navigation and is handled by the [classname]`AccessDeniedExceptionHandler` that keeps the `MainLayout` with its menu bar, but displays information that an exception has occurred.

Expand Down Expand Up @@ -239,14 +229,15 @@ public class FaultyBlogPostHandler extends Component


[role="since:com.vaadin:[email protected]"]
== Show Error View for Exception during RPC Call
== Error View for Exception during RPC Call

To use registered error views outside routing and rerouting, the application can set the `enableErrorHandlerRedirect` parameter to `true`.
Vaadin Flow shows the registered error views if an exception occurs outside routing and rerouting. An example of this is when a button-click event is fired during a remote procedure call (i.e., RPC) on a server.

This enables updating the current view content to a registered [interfacename]`HasErrorParameter<T extends Exception>` that handles the exact exception thrown for RPC events.

If you're using a custom [interfacename]`ErrorHandler`, see the <<{articles}/advanced/custom-error-handler#, Showing Error Parameter Views For Non-Navigation Exceptions>> page on this feature.
If you're using a custom [interfacename]`ErrorHandler`, see the <<{articles}/advanced/custom-error-handler#, Showing Error Parameter Views For Non-Navigation Exceptions>> page for information on this feature.

If this redirection isn't desired, you can provide a custom error handler implementation without a redirect to error view. See the <<{articles}/advanced/custom-error-handler#, Custom Error Handling>> page for more on this.

[discussion-id]`F4039D66-C9C5-4CEE-B49A-F1224B46C5E8`

Expand Down

0 comments on commit 28c492a

Please sign in to comment.