Magnolia 6.1 reached end of life on March 31, 2021. This branch is no longer supported, see End-of-life policy.
Consider the error severity, then choose the right message type and send it to the right people.
Look at the severity of the error. If it is severe, show it in a notification banner. Who needs to know about it? Typically the logged-in user only, not everybody. Each visual element in the Magnolia UI is designed to carry a specific type of message. Every message type has characteristics you should be familiar with so that you can choose the right vehicle.
Validate input and check preconditions early on.
Notification is the best choice for severe errors because the system stores message and it can be forwarded and analyzed further.
|Severity||Message type||Send to|
|Critical errors (exceptions)||Notification||Logged-in user|
|Severe errors (exceptions that leave the app in a bad state)||Notification||Logged-in user, administrator|
|Security breaches or similar||Notification||Administrator|
Show an alert when the user must see the error. It's a good idea to show an alert also if your app must abort the task or the task needs input from the user before it can continue.
Never use a pop-up to signal errors. Pop-ups are too easy to miss. Instead, put more effort on validation before kicking off the action. You should only use a pop-up to confirm that an action was aborted. For example, if the user uploads a file and decides to cancel the running upload, it's OK to show a pop-up to confirm that the upload was aborted. The user can also determine that the upload was cancelled by looking at the UI: no progress bar anymore but also no uploaded files.
Don't broadcast errors to all users. Error messages are typically only relevant for users who caused it. Only the current user can fix the error or recover from it. Other users consider such messages noise. If the end user cannot correct the error then you may need to send it also to the superuser or administrator group.
Error messages must be detailed so they can be properly dealt with. If all you do is throw a single type of exception to signal errors in code, you are probably on the wrong track. Exceptions are also pretty bad performance-wise: raising them needs a lot of processing power and memory.