[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-03-31 UTC."],[[["\u003cp\u003eError messages should clearly identify the cause of the error, including specific invalid values or unmet requirements.\u003c/p\u003e\n"],["\u003cp\u003eProvide clear instructions on how to fix the problem, potentially using examples for better understanding.\u003c/p\u003e\n"],["\u003cp\u003eWrite concise and understandable messages, using consistent terminology and appropriate language for the target audience.\u003c/p\u003e\n"],["\u003cp\u003eMaintain a positive and helpful tone without excessive apologies.\u003c/p\u003e\n"]]],["Error messages should identify the cause, including invalid values and constraints. Explain the solution, using examples when helpful. Write clearly by being concise, avoiding double negatives, using consistent terminology, and targeting the appropriate audience. Format long messages well. Maintain a positive tone without being overly apologetic. These best practices are recommended for general error messages.\n"],null,["# Course summary\n\n\u003cbr /\u003e\n\nThis course recommended the following best practices when writing\nerror messages:\n\n- Identify the cause of the error.\n - If the user entered an invalid value, specify the invalid value.\n - Specify requirements and constraints, such as required permissions or minimum RAM.\n- Explain how to fix the problem.\n - When appropriate, provide an example to help demonstrate the fix.\n- Write clearly.\n - Be concise, not wordy. However, don't be so concise that the resulting error message becomes cryptic.\n - Avoid double negatives and exceptions to exceptions.\n - Aim the message at the appropriate target audience. Words appropriate for software engineers are often inappropriate for non-technical users.\n - Use terminology consistently. For example, don't use the term *directory* in one part of an error message and a *folder* in another part.\n - Format long error messages carefully, possibly using progressive disclosure or links to expanded documentation.\n - Set a positive tone.\n - Don't be overly apologetic.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Next unit:** [Additional guidelines for back end engineers](/tech-writing/error-messages/back-end)"]]