summaryrefslogtreecommitdiffstats
path: root/documentation/application/application-errors.asciidoc
blob: 8f4aa8f0403de4d1c0b65ad6319e244893c9f505 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
---
title: Handling Errors
order: 6
layout: page
---

[[application.errors]]
= Handling Errors

[[application.errors.error-indicator]]
== Error Indicator and Message

All components have a built-in error indicator that is turned on if validating
the component fails, and can be set explicitly with
[methodname]#setComponentError()#. Usually, the error indicator is placed right
of the component caption. The error indicator is part of the component caption,
so its placement is usually managed by the layout in which the component is
contained, but some components handle it themselves. Hovering the mouse pointer
over the field displays the error message.


[source, java]
----
textfield.setComponentError(new UserError("Bad value"));
button.setComponentError(new UserError("Bad click"));
----

The result is shown in <<figure.application.errors.error-indicator>>.

[[figure.application.errors.error-indicator]]
.Error Indicator Active
image::img/errorindicator-example2.png[scaledwidth=40%]

[[application.errors.reconnect]]
== Connection Fault

If the connection to the server is lost, Vaadin application shows a "lost connection" notification
and tries to restore the connection. After several retries, an error message is shown.
You can customize the messages, timeouts, and the number of reconnect attempts in the [classname]#ReconnectDialogConfiguration#
object, which you can access from your [classname]#UI# with [methodname]#getReconnectDialogConfiguration()#.

[[application.errors.systemmessages]]
== Customizing System Messages

System messages are notifications that indicate a major invalid state that
usually requires restarting the application. Session timeout is perhaps the most
typical such state.

System messages are strings managed in the [classname]#SystemMessages# class.
Each message has four properties: a short caption, the actual message, a URL to
which to redirect after displaying the message, and property indicating whether
the notification is enabled.

You can override the default system messages by setting the
[interfacename]#SystemMessagesProvider# in the [classname]#VaadinService#. You
need to implement the [methodname]#getSystemMessages()# method, which should
return a [classname]#SystemMessages# object. The easiest way to customize the
messages is to use a [classname]#CustomizedSystemMessages# object.

You can set the system message provider in the
[methodname]#servletInitialized()# method of a custom servlet class, for example
as follows:


[source, java]
----
getService().setSystemMessagesProvider(
    new SystemMessagesProvider() {
    @Override
    public SystemMessages getSystemMessages(
        SystemMessagesInfo systemMessagesInfo) {
        CustomizedSystemMessages messages =
                new CustomizedSystemMessages();
        messages.setCommunicationErrorCaption("Comm Err");
        messages.setCommunicationErrorMessage("This is bad.");
        messages.setCommunicationErrorNotificationEnabled(true);
        messages.setCommunicationErrorURL("http://vaadin.com/");
        return messages;
    }
});
----

See
<<dummy/../../../framework/application/application-lifecycle#application.lifecycle.servlet-service,"Vaadin
Servlet, Portlet, and Service">> for information about customizing Vaadin
servlets.

[[application.errors.unchecked-exceptions]]
== Handling Uncaught Exceptions

Handling events can result in exceptions either in the application logic or in
the framework itself, but some of them may not be caught properly by the
application. Any such exceptions are eventually caught by the framework. It
delegates the exceptions to the [classname]#DefaultErrorHandler#, which displays
the error as a component error, that is, with a small red "!" -sign (depending
on the theme). If the user hovers the mouse pointer over it, the entire
backtrace of the exception is shown in a large tooltip box.


You can customize the default error handling by implementing a custom
[interfacename]#ErrorHandler# and enabling it with
[methodname]#setErrorHandler()# in any of the components in the component
hierarchy, including the [classname]#UI#, or in the [classname]#VaadinSession#
object. You can either implement the [interfacename]#ErrorHandler# or extend the
[classname]#DefaultErrorHandler#. In the following example, we modify the
behavior of the default handler.


[source, java]
----
// Here's some code that produces an uncaught exception
final VerticalLayout layout = new VerticalLayout();
final Button button = new Button("Click Me!", event ->
        ((String)null).length()); // Null-pointer exception
layout.addComponent(button);

// Configure the error handler for the UI
UI.getCurrent().setErrorHandler(new DefaultErrorHandler() {
    @Override
    public void error(com.vaadin.server.ErrorEvent event) {
        // Find the final cause
        String cause = "<b>The click failed because:</b><br/>";
        for (Throwable t = event.getThrowable(); t != null;
             t = t.getCause())
            if (t.getCause() == null) // We're at final cause
                cause += t.getClass().getName() + "<br/>";

        // Display the error message in a custom fashion
        layout.addComponent(new Label(cause, ContentMode.HTML));

        // Do the default error handling (optional)
        doDefault(event);
    }
});
----

The above example also demonstrates how to dig up the final cause from the cause
stack.

When extending [classname]#DefaultErrorHandler#, you can call
[methodname]#doDefault()# as was done above to run the default error handling,
such as set the component error for the component where the exception was
thrown. See the source code of the implementation for more details. You can call
[methodname]#findAbstractComponent(event)# to find the component that caused the
error. If the error is not associated with a component, it returns null.