|
| 1 | +# Error handling |
| 2 | + |
| 3 | +This page describes which coding patterns are used by fractal-web to handle various error cases. |
| 4 | + |
| 5 | +## Fractal-server errors structure |
| 6 | + |
| 7 | +Fractal-server error responses payloads are usually JSON structures having the error under a `detail` key. This is not true for the 500 Internal Server Error, which doesn't provide a JSON payload. |
| 8 | + |
| 9 | +Generic fractal-server errors contain the error message string directly as `detail` value or as an array of values: |
| 10 | + |
| 11 | +```json |
| 12 | +{ "detail": "this is the error message" } |
| 13 | +``` |
| 14 | + |
| 15 | +```json |
| 16 | +{ "detail": ["this is also an error"] } |
| 17 | +``` |
| 18 | + |
| 19 | +Validation errors associated with a specific request field are represented using a `loc` array that describes the position of the invalid field in the request payload: |
| 20 | + |
| 21 | +```json |
| 22 | +{ |
| 23 | + "detail": [ |
| 24 | + { |
| 25 | + "loc": [ |
| 26 | + "body", |
| 27 | + "zarr_url" |
| 28 | + ], |
| 29 | + "msg": "URLs must begin with '/' or 's3'.", |
| 30 | + "type": "value_error" |
| 31 | + } |
| 32 | + ] |
| 33 | +} |
| 34 | +``` |
| 35 | + |
| 36 | +Some validation errors may not be associated with a specific field and in that case their `loc` array will reference a `__root__` element: |
| 37 | + |
| 38 | +```json |
| 39 | +{ |
| 40 | + "detail": [ |
| 41 | + { |
| 42 | + "loc": [ |
| 43 | + "body", |
| 44 | + "__root__" |
| 45 | + ], |
| 46 | + "msg": "error message", |
| 47 | + "type": "value_error" |
| 48 | + } |
| 49 | + ] |
| 50 | +} |
| 51 | +``` |
| 52 | + |
| 53 | +The goal of fractal-web is to extract the error message and display it inside an alert component or directly near the invalid form field, when possible. If an unexpected JSON structure is received, fractal-web will display the error JSON payload as it is, but that should happen rarely, except for the JSON Schema form, whose errors may result in some complex payloads. |
| 54 | + |
| 55 | +## Error responses in Svelte backend (SSR) |
| 56 | + |
| 57 | +Files in `src/lib/server/api` provide API calls to fractal-server to be used from Svelte backend. These calls are usually required to be successful in order to properly display the page, since they retrieve the main resources of the page. A failure at this level is usually a 404 error (e.g. attempting to open a project with a non existent id) or something really severe (500 errors). For this reason the API calls errors happening on Svelte backend should usually be directly propagated, in order to display the error code inside the page. |
| 58 | + |
| 59 | +The utility function `responseError()` (in `error.js`) can be used to propagate the error in these cases. It will throw an exception if an error response is detected, automatically extracting the `detail`. |
| 60 | + |
| 61 | +It is suggested to handle the unsuccessful response first, in order to return the payload at the end of the function. |
| 62 | + |
| 63 | +```javascript |
| 64 | +if (!response.ok) { |
| 65 | + await responseError(response); |
| 66 | +} |
| 67 | +return await response.json(); |
| 68 | +``` |
| 69 | + |
| 70 | +In this way it is easier to define properly the type of the response using JSDoc annotation. |
| 71 | + |
| 72 | +## Error responses in Svelte frontend |
| 73 | + |
| 74 | +### The AlertError class |
| 75 | + |
| 76 | +The `AlertError` class represents errors handled by fractal-web that has to be displayed somewhere. It has a constructor that receives an object or string representing the error and an optional status code (if the error was originated from an unsuccessful API call). |
| 77 | + |
| 78 | +It can be used to istantiate a new error message; this is mostly used when we need to propagate an error from a component to another, that will catch the error: |
| 79 | + |
| 80 | +```javascript |
| 81 | +throw new AlertError('Invalid JSON schema'); |
| 82 | +``` |
| 83 | + |
| 84 | +Most of the time it is used to handle an unsuccessful API response; the status code is used to check if it is a validation error (status is equals to 422) and it automatically extracts the message from the detail: |
| 85 | + |
| 86 | +```javascript |
| 87 | +const result = await response.json(); |
| 88 | +throw new AlertError(result, response.status); |
| 89 | +``` |
| 90 | + |
| 91 | +### The standard error alert |
| 92 | + |
| 93 | +It is possible to use the `displayStandardErrorAlert()` function to display a generic error inside an Bootstrap alert component. The function returns a reference to a `StandardErrorAlert` component, that can be used to hide the error invoking its `hide()` function. |
| 94 | + |
| 95 | +Inside the page we have to add a div for the alert component, with a defined id: |
| 96 | + |
| 97 | +```html |
| 98 | +<div id="errorAlert-projectInfoModal" /> |
| 99 | +``` |
| 100 | + |
| 101 | +Then we have to define a variable for the alert component: |
| 102 | + |
| 103 | +```javascript |
| 104 | +/** @type {import('$lib/components/common/StandardErrorAlert.svelte').default|undefined} */ |
| 105 | +let errorAlert = undefined; |
| 106 | +``` |
| 107 | + |
| 108 | +Finally, we invoke the function to display the error: |
| 109 | + |
| 110 | +```javascript |
| 111 | +errorAlert = displayStandardErrorAlert( |
| 112 | + new AlertError(result, response.status), |
| 113 | + 'errorAlert-projectInfoModal' |
| 114 | +); |
| 115 | +``` |
| 116 | + |
| 117 | +If we need to hide the error (for example before clicking a submit button again), we can invoke the `hide()` function. |
| 118 | + |
| 119 | +```javascript |
| 120 | +errorAlert?.hide(); |
| 121 | +``` |
| 122 | +
|
| 123 | +Notice that we are using the optional chaining operator (`?.`), since the variable might be undefined if no error happened previously. |
| 124 | +
|
| 125 | +### Form validation errors |
| 126 | +
|
| 127 | +A form usually needs an error alert component to display generic errors and a mechanism to display errors associated with specific form fields. This logic has been incapsulated in the `FormErrorHandler` class. |
| 128 | +
|
| 129 | +The constructor accepts as first argument the id of the div that will contain the generic error message and as second argument an array containing all the fields that correspond with some input fields in the form. |
| 130 | +
|
| 131 | +```javascript |
| 132 | +const formErrorHandler = new FormErrorHandler('taskCollectionError', [ |
| 133 | + 'package', |
| 134 | + 'package_version', |
| 135 | + 'package_extras', |
| 136 | + 'python_version' |
| 137 | +]); |
| 138 | +``` |
| 139 | +
|
| 140 | +Once created, it is possible to retrieve the `validationErrors` object from the form error handler: |
| 141 | +
|
| 142 | +```javascript |
| 143 | +const validationErrors = formErrorHandler.getValidationErrorStore(); |
| 144 | +``` |
| 145 | +
|
| 146 | +This is a Svelte store referencing a map of errors, so it has to be accessed prepending the `$` symbol: `$validationErrors`, as shown in the example above. |
| 147 | +
|
| 148 | +The Bootstrap validation classes are used inside the form: `has-validation` on parent, `is-invalid` on the invalid field and `invalid-feedback` for the message. |
| 149 | +
|
| 150 | +```svelte |
| 151 | +<div class="input-group has-validation"> |
| 152 | + <div class="input-group-text"> |
| 153 | + <label class="font-monospace" for="package">Package</label> |
| 154 | + </div> |
| 155 | + <input |
| 156 | + name="package" |
| 157 | + id="package" |
| 158 | + type="text" |
| 159 | + class="form-control" |
| 160 | + required |
| 161 | + class:is-invalid={$validationErrors['package']} |
| 162 | + bind:value={python_package} |
| 163 | + /> |
| 164 | + <span class="invalid-feedback">{$validationErrors['package']}</span> |
| 165 | +</div> |
| 166 | +``` |
| 167 | + |
| 168 | +The `handleErrorResponse()` function is used to populate the fields from an error response: |
| 169 | + |
| 170 | +```javascript |
| 171 | +if (!response.ok) { |
| 172 | + await formErrorHandler.handleErrorResponse(response); |
| 173 | +} |
| 174 | +``` |
| 175 | + |
| 176 | +The class also provides a `clearErrors()` function and some functions to manually add or remove errors (`addValidationError()`, `removeValidationError()`, `setGenericError()`); these are useful to handle some validation directly on the frontend (e.g. required fields), without performing any API calls. |
0 commit comments