docs: add a Building Apps guide on application-wide error handling

articles/building-apps/security/protect-views.adoc

@@ -288,7 +288,7 @@ Leaving out, hiding, disabling, and write-protecting components decides *what us
 
 Always enforce the same rules in the *services* the view calls, as described in the <<protect-services#,Protect Services>> guide. Treat the checks inside the view as a way to give users a relevant UI, and the checks in the services as the actual security boundary.
 
-If a view still calls a service method that the current user isn't allowed to call, Spring Security throws an [classname]`AccessDeniedException`. This points to a bug in the view, since the view shouldn't offer an action that the user can't perform. Unless the view catches the exception, Vaadin passes it to the session's error handler. To show the user a clear message rather than a generic error, install a custom error handler that recognizes the exception, as described in <<{articles}/flow/advanced/custom-error-handler#,Custom Error Handling>>.
+If a view still calls a service method that the current user isn't allowed to call, Spring Security throws an [classname]`AccessDeniedException`. This points to a bug in the view, since the view shouldn't offer an action that the user can't perform. Unless the view catches the exception, Vaadin passes it to the session's error handler. To show the user a clear message rather than a generic error, install a custom error handler that recognizes the exception, as described in <<../ui-basics/handle-errors#access-denied-by-a-service,Handle Errors>>. The same guide also shows how to customize what users see when they navigate to a view that they aren't allowed to access.
 
 
 == Role Constants