Docs

Docs

Router Exception Handling

Handling router exceptions with the Router class.

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

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

Errors in navigation are resolved to a target that’s based on the exception type thrown during navigation.

At startup, all classes implementing the HasErrorParameter<T extends Exception> interface are collected for use as exception targets during navigation. An example of such a class is RouteNotFoundError. It’s included by default in the framework and is used to resolve errors related to the router’s NotFoundException.

In the example here, RouteNotFoundError defines the default target for the NotFoundException that’s shown when there is no target for the given URL:

@Tag(Tag.DIV)
public class RouteNotFoundError extends Component
       implements HasErrorParameter<NotFoundException> {

    @Override
    public int setErrorParameter(BeforeEnterEvent event,
          ErrorParameter<NotFoundException> parameter) {
        getElement().setText("Could not navigate to '"
                    + event.getLocation().getPath()
                    + "'");
        return HttpServletResponse.SC_NOT_FOUND;
    }
}

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

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

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 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 eagerServerLoad property, the initial JSON data fragment is part of the first request’s response. It includes the 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:

@ParentLayout(MainLayout.class)
public class CustomNotFoundTarget
        extends RouteNotFoundError {

    @Override
    public int setErrorParameter(BeforeEnterEvent event,
          ErrorParameter<NotFoundException> parameter) {
        getElement().setText(
                "My custom not found class!");
        return HttpServletResponse.SC_NOT_FOUND;
    }
}

Only extending instances are allowed. Exception targets may define ParentLayouts. BeforeNavigationEvent and AfterNavigationEvent are still sent, as with normal navigation. One exception may only have one exception handler.

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 ProtectedWidget in error, the widget itself checks authentication on creation and throws an CustomAccessDeniedException.

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

@Route(value = "dashboard", layout = MainLayout.class)
@Tag(Tag.DIV)
public class Dashboard extends Component {
    public Dashboard() {
        init();
    }

    private void init() {
        getWidgets().forEach(this::addWidget);
    }

    public void addWidget(Widget widget) {
        // Implementation omitted
    }

    private Stream<Widget> getWidgets() {
        // Implementation omitted, gets faulty state
        // widget
        return Stream.of(new ProtectedWidget());
    }
}

public class ProtectedWidget extends Widget {
    public ProtectedWidget() {
        if (!AccessHandler.getInstance()
                .isAuthenticated()) {
            throw new CustomAccessDeniedException(
                    "Unauthorized widget access");
        }
        // Implementation omitted
    }
}

@Tag(Tag.DIV)
public abstract class Widget extends Component {
    public boolean isProtected() {
        // Implementation omitted
        return true;
    }
}

@Tag(Tag.DIV)
@ParentLayout(MainLayout.class)
@PermitAll
public class AccessDeniedExceptionHandler
     extends Component
     implements HasErrorParameter<CustomAccessDeniedException>
{

    @Override
    public int setErrorParameter(BeforeEnterEvent event,
            ErrorParameter<CustomAccessDeniedException>
                    parameter) {
        getElement().setText(
            "Tried to navigate to a view without "
            + "correct access rights");
        return HttpServletResponse.SC_FORBIDDEN;
    }
}

public class CustomAccessDeniedException extends RuntimeException {
}

The example above uses @PermitAll, but @RolesAllowed can also be used. @AnonymousAllowed isn’t recommended for error views handling access denied exceptions, as it exposes information about access restrictions to the anonymous users.

Rerouting to Error View

It’s possible to reroute from the BeforeEnterEvent and BeforeLeaveEvent to an error view registered for an exception. You can use one of the rerouteToError() method overloads. You need only to add the exception class to the target, and a custom error message, where necessary.

This example shows how to reroute to an error view:

public class AuthenticationHandler
        implements BeforeEnterObserver {
    @Override
    public void beforeEnter(BeforeEnterEvent event) {
        Class<?> target = event.getNavigationTarget();
        if (!currentUserMayEnter(target)) {
            event.rerouteToError(
                    CustomAccessDeniedException.class);
        }
    }

    private boolean currentUserMayEnter(
            Class<?> target) {
        // implementation omitted
        return false;
    }
}

If the rerouting method catches an exception, you can use the rerouteToError(Exception, String) method to set a custom message. Re-routing to a custom access denial view is also possible with annotation @AccessDeniedErrorRouter. See Customizing Error Messages for Unauthorized Views for more on this.

This next example shows a blog sample error view with a custom message:

@Tag(Tag.DIV)
public class BlogPost extends Component
        implements HasUrlParameter<Long> {

    @Override
    public void setParameter(BeforeEvent event,
            Long parameter) {
        removeAll();

        Optional<BlogRecord> record =
                getRecord(parameter);

        if (!record.isPresent()) {
            event.rerouteToError(
                   IllegalArgumentException.class,
                   getTranslation("blog.post.not.found",
                        event.getLocation().getPath()));
        } else {
            displayRecord(record.get());
        }
    }

    private void removeAll() {
        // NO-OP
    }

    private void displayRecord(BlogRecord record) {
        // NO-OP
    }

    public Optional<BlogRecord> getRecord(Long id) {
        // Implementation omitted
        return Optional.empty();
    }
}

@Tag(Tag.DIV)
@AnonymousAllowed
public class FaultyBlogPostHandler extends Component
  implements HasErrorParameter<IllegalArgumentException>
{

    @Override
    public int setErrorParameter(BeforeEnterEvent event,
            ErrorParameter<IllegalArgumentException>
                    parameter) {
        Label message = new Label(
                parameter.getCustomMessage());
        getElement().appendChild(message.getElement());

        return HttpServletResponse.SC_NOT_FOUND;
    }
}

HasErrorParameter error view needs an access control annotation so that Vaadin Flow allows navigation to it. The example above uses @AnonymousAllowed, but @PermitAll or @RolesAllowed can also be used.

Error View for Exception during RPC Call

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 HasErrorParameter<T extends Exception> that handles the exact exception thrown for RPC events.

If you’re using a custom ErrorHandler, see the 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 Custom Error Handling page for more on this.

F4039D66-C9C5-4CEE-B49A-F1224B46C5E8