Message ошибка что такое

ERROR_MESSAGE (Transact-SQL)

Применимо к: SQL Server (все поддерживаемые версии) База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics Параллельное хранилище данных

Эта функция возвращает текст сообщения об ошибке, которая вызвала выполнение блока CATCH конструкции TRY. CATCH.

Синтаксические обозначения в Transact-SQL

Синтаксис

Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.

Типы возвращаемых данных

nvarchar(4000)

Возвращаемое значение

При вызове в блоке CATCH функция ERROR_MESSAGE возвращает полный текст сообщения об ошибке, запустившей блок CATCH . Текст содержит значения подставляемых параметров, таких как длина, имена объектов или время.

Функция ERROR_MESSAGE возвращает значение NULL в случае вызова вне блока CATCH.

Функцию ERROR_MESSAGE можно вызывать в любом месте области действия блока CATCH.

Функция ERROR_MESSAGE возвращает соответствующее сообщение об ошибке независимо от количества ее выполнений или от места ее вызова в области действия блока CATCH . В этом ее отличие от таких функций, как @@ERROR, которые возвращают номер ошибки только в той инструкции, которая непосредственно следует за инструкцией, вызвавшей ошибку.

Во вложенных блоках CATCH функция ERROR_MESSAGE возвращает сообщение об ошибке, соответствующее области действия блока CATCH , который ссылался на данный блок CATCH . Например, блок CATCH внешней конструкции TRY. CATCH может содержать внутреннюю конструкцию TRY. CATCH . Во внутреннем блоке CATCH функция ERROR_MESSAGE возвращает сообщение об ошибке, вызвавшей внутренний блок CATCH . Если функция ERROR_MESSAGE выполняется во внешнем блоке CATCH , она возвращает сообщение об ошибке, вызвавшей внешний блок CATCH .

Примеры

A. Использование функции ERROR_MESSAGE в блоке CATCH

В приведенном ниже примере показана инструкция SELECT , вызывающая ошибку деления на ноль. Блок CATCH возвращает сообщение об ошибке.

Б. Использование функции ERROR_MESSAGE в блоке CATCH с другими средствами обработки ошибок

В приведенном ниже примере показана инструкция SELECT , вызывающая ошибку деления на ноль. Вместе с сообщением об ошибке блок CATCH возвращает сведения о ней.

Источник

MS SQL 2011 — Обработка ошибок

Новое полезное дополнение для SQL Server 2011 (Denali) ­– выражение Throw. Разработчики на .Net уже догадались наверно, где и как оно будет использоваться.

Это слово может использоваться в сочетании с управляющей конструкцией Try…Catch и позволяет послать уведомление о возникновении ошибки времени исполнения. Когда возникает исключение, программа ищет ближайший по иерархии вверх блок Catch который может обработать исключение. Используя это выражение внутри блока Catch можно изменить вывод ошибки. Более того, теперь вызывать исключение можно произвольно в любом месте скрипта.

Далее рассмотрим различные способы поимки исключении, которые предоставляет SQL Server начиная с версии 2000 и до версии 2011, с указанием плюсов и минусов.

Для всех рассматриваемых случаев будет использоваться таблица tbl_ExceptionTest.

Для того, чтобы не протыкивать дизайнер мышью, можно выполнить следующий скрипт для создания искомой таблицы (сгенерировано автоматически).

Далее будем пытаться добавить в таблицу несколько записей и при внесении неподходящих данных в колонку Phone Number генерировать исключения.

Обработка ошибок в SQL Server 2000 (Sphinx)

Использование глобальной переменной @@ERROR

Возвращаясь во времена использования SQL Server 2000, вспоминаем что использование переменной @@Error было на тот момент самым прогрессивным и эффективным способом обработки ошибок. Данная переменная отвечала за возврат целочисленного значения ошибки, которое произошло в последнем выполненном выражении. Значение ошибки могло быть как положительным, так и отрицательным, лишь 0 указывал на успешность выполнения операции. Значение переменной менялось после каждого выполненного выражения.

Посмотрим на использование @@Error в действии.

Общий смысл скрипта сводиться к тому, что в последней записи мы намеренно вызываем ошибку и читаем ее значение из локальной переменной. Если значение ошибки не равно нулю, то показываем осмысленное предупреждение пользователю. Если ошибок нет, то сохраняем результаты.

Выполнение данного скрипта приведет к появлению ошибки, как показано ниже

Msg 515, Level 16, State 2, Line 26 Cannot insert the value NULL into column ‘Phone Number’, table ‘tempdb.dbo.#tblExceptionTest_____000000000023’; column does not allow nulls. INSERT fails. The statement has been terminated. Msg 50000, Level 16, State 1, Line 43 Attempt to insert null value in [Phone Number] is not allowed

Естественно, что вся транзакция откатится назад и ничего не будет внесено в таблицу.

Недостатки подхода с использованием @@Error

• Значение переменной @@Error должно быть проверено сразу после выполнения запроса/команды.
• Так как @@Error постоянно меняется, то мы вынуждены заводить отдельную переменную для сохранения и вывода кода ошибки.
• Вместе со специальным сообщением об ошибке указывающей на логический смысл ошибки выводится техническая информация, которая пользователям не интересна.

Если вы хотите узнать больше деталей и нюансов по использованию @@Error, то советую обратиться к статье про @@Error.

Использование глобальной переменной @@TRANCOUNT

Эта переменная возвращает количество транзакций выполняющихся в момент обращения к переменной. Из описания уже понятно, что она постоянна примерно в той же мере, что и @@ERROR, т.е. постоянно меняется во время исполнения транзакций. Это опять подводит нас к тому, чтобы использовать локальные переменные для хранения значений в интересующий момент времени.

Каждый вызов BEGIN TRANSACTION увеличивает значение @@TRANCOUNT на 1 и каждый вызов COMMIT TRANSACTION уменьшает ее значение на 1. ROLLBACK TRANSACTION не изменяет значения @@TRANCOUNT. Записи считаются внесенными только когда значение @@TRANCOUNT достигнет 0.

Рассмотрим использование @@TRANCOUNT на следующем примере.

В данном скрипте мы опираемся на количество закрытых транзакций. Транзакции могут быть вложенные, так что такой способ имеет право на существование.

Для получения дополнительной информации по @@TRANCOUNT обратитесь на MSDN.

Использование глобальной переменной @@ROWCOUNT

Данная переменная возвращает количество измененных строк в результате выполнения запроса/команды.

Поведение такое же, как и у предыдущих двух, так что сохраняем промежуточные результаты в локальную переменную для последующего анализа.

В данном случае мы ожидаем, что вставится одна запись в таблицу, но если количество вставленных записей равно нулю, то явно что-то не в порядке.
Для того, чтобы получить больше деталей по использованию @@ROWCOUNT читайте MSDN.

Обработка ошибок в SQL Server 2005/2008 (Yukon/Katmai)

После вывода на рынок SQL Server 2005 и развития его идей в SQL Server 2008 у разработчиков на TSql появился новый блок Try…Catch. Теперь стало возможно перехватывать исключения без потери транзакционного контекста.

Пример на использование блока Try … Catch.

В примере больше не используется вспомогательных переменных для определения ошибки выполнения скрипта по косвенным признакам.

После запуска скрипта получим сообщение следующего вида:

Msg 50000, Level 16, State 1, Line 45 Attempt to insert null value in [Phone Number] is not allowed

Как вы уже наверно заметили, на этот раз вывелось только то, что было задано в сообщении об ошибке. Никаких дополнительных, смущающих пользователя сообщений, SQL Server не показал. Выполняемый код обрамлен в блоке try и обработка ошибки в блоке catch. Получается чистый и ясный для понимания код. Если весь желаемый код прошел без ошибок, то код из блока Catch не будет вызван.

Самое важное то, что Catch блок представляет набор функций для детального разбора причин ошибки и возможность информирования пользователя на должном уровне. Функции для разбора исключительной ситуации:

• ERROR_NUMBER
• ERROR_SEVERITY
• ERROR_STATE
• ERROR_LINE
• ERROR_PROCEDURE
• ERROR_MESSAGE

С помощью этих функций попробуем переписать Catch блок скрипта, что бы представлен до этого.

Теперь мы получим такой ответ от сервера:

Недостатки использования функции RaiseError

1 Если вспомнить, что показывала эта функция вызванная в Catch блоке, то заметим, что она ссылалась на строку номер 45, как источник проблем.

Однако в действительности ошибка произошла в строке номер 24, так где было написано

Insert into #tblExceptionTest([Phone Number]) Values(null)

В то время как функция ERROR_LINE() возвращает всегда реальное место возникновения ошибки. Еще один способ, чтобы показать работу новых функций будет такой:

В этом случае движок SQL Server выдаст такое сообщение:

Из чего можно заключить, что использование RaiseError не дает возможности указать на реальное место в скрипте, где произошла исключительная ситуация.

2 Следующий недостаток функции RaiseError состоит в том, что нет возможности повторно инициировать тоже самое исключение, для передачи вверх по иерархии вызовов. Так, если переписать блок Catch как показано ниже

То полученное сообщение об ошибке будет таким:

Msg 2732, Level 16, State 1, Line 46 Error number 515 is invalid. The number must be from 13000 through 2147483647 and it cannot be 50000

Причной этого является то, что для инициирования нового сообщения об ошибке, номер ошибки должен содержаться в таблице sys.messages.

Обработка ошибок в SQL Server 2011 (Denali)

Упомянутые выше недостатки функции RaiseError могут быть успешно преодолены с помощью новой команды Throw.

Первый недостаток функции RaiseError, на который мы указали ранее, невозможность сослаться на точную строку возникновения ошибки. Рассмотрим насколько далеко от места возникновения ошибки мы оказываемся при использовании команды Throw.

Перепишем блок Catch с использованием команды Throw.

Вывод будет таким:

Это точно то место, где произошла ошибка. Что ж, работает пока на отлично.

Вторым недостатком было то, что функция RaiseError не может повторно инициировать исключение потому, что RAISE ERROR ожидает номер ошибки, который хранится в таблице sys.messages. Команда Throw не ожидает, что номер ошибки должен быть из диапазона системной таблицы sys.messages, однако номер можно задать из диапазона от 50000 до 2147483647 включительно.

Снова изменим блок Catch в соответствии с новыми знаниями.

Результатом возникновения исключения будет

Msg 50001, Level 16, State 1, Line 45 Attempt to insert null value in [Phone Number] is not allowed

На данный момент SQL Server предоставляет множество путей для отлова ошибок, но до сих пор не все ошибки могут быть пойманы с помощью блока Try…Catch. Например:

• Синтаксические ошибки отлавливаются редактором запросов в SSMS
• Неправильные имена объектов

Если попробовать подать на выполнение следующий скрипт:

Получим сообщение об ошибке следующего плана:

Msg 208, Level 16, State 0, Line 3 Invalid object name ‘tblInvalid’.

Получается что почти невозможно перехватить такие типы ошибок.

Но. Как всегда есть небольшой трюк как осуществить желаемое. Основная идея в том, чтобы сделать две хранимых процедуры и вызывать одну из другой в блоке Try…Catch и ловить исключение. Для доказательства нашего предположения используем для экспериментов следующий скрипт.

При запуске процедуры ExternalStoredProc получим сообщение:

И панель Result отобразит следующие данные:

Что нам и требовалось!

Теперь немного объяснений как работает код. У нас есть 2 хранимых процедуры: usp_InternalStoredProc и usp_ExternalStoredProc. В usp_InternalStoredProc мы пытаемся вставить запись в несуществующую таблицу #tblInnerTempTable, в результате чего получаем исключительную ситуацию, которая в свою очередь отлавливается внешним блоком Catch, расположенным во внешней процедуре.

Более того, строка и текст ошибки полностью соответствуют нашим ожиданиям и указывают на точное место.

Очень важно не забыть закрыть точкой с запятой предстоящее перед THROW выражение во внешней процедуре. THROW должен быть новым набором команд. В противном случае получите ошибку

Incorrect syntax near ‘THROW’.

Больше детальной информации о THROW можно подчерпнуть из MSDN.

Источник

Error Messages (Design basics)

This design guide was created for Windows 7 and has not been updated for newer versions of Windows. Much of the guidance still applies in principle, but the presentation and examples do not reflect our current design guidance.

An error message alerts users of a problem that has already occurred. By contrast, a warning message alerts users of a condition that might cause a problem in the future. Error messages can be presented using modal dialog boxes, in-place messages, notifications, or balloons.

A typical modal error message.

Effective error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. Users should either perform an action or change their behavior as the result of an error message.

Well-written, helpful error messages are crucial to a quality user experience. Poorly written error messages result in low product satisfaction, and are a leading cause of avoidable technical support costs. Unnecessary error messages break users’ flow.

Note: Guidelines related to dialog boxes, warning messages, confirmations, standard icons, notifications, and layout are presented in separate articles.

Is this the right user interface?

To decide, consider these questions:

• Is the user interface (UI) presenting a problem that has already occurred? If not, the message isn’t an error. If the user being alerted of a condition that might cause a problem in the future, use a warning message.
• Can the problem be prevented without causing confusion? If so, prevent the problem instead. For example, use controls that are constrained to valid values instead of using unconstrained controls that may require error messages. Also, disable controls when clicking would result in error, as long as it’s obvious why the control is disabled.
• Can the problem be corrected automatically? If so, handle the problem and suppress the error message.
• Are users likely to perform an action or change their behavior as the result of the message? If not, the condition doesn’t justify interrupting the user so it’s better to suppress the error.
• Is the problem relevant when users are actively using other programs? If so, consider showing the problem using a notification area icon.
• Is the problem not related to the current user activity, does it not require immediate user action, and can users freely ignore it? If so, use an action failure notification instead.
• Does the problem relate to the status of a background task within a primary window? If so, consider showing the problem using a status bars.
• Are the primary target users IT professionals? If so, consider using an alternative feedback mechanism, such as log file entries or e-mail alerts. IT professionals strongly prefer log files for non-critical information.

Design concepts

The characteristics of poor error messages

It should be no surprise that there are many annoying, unhelpful, and poorly written error messages. And because error messages are often presented using modal dialogs, they interrupt the user’s current activity and demand to be acknowledged before allowing the user to continue.

Part of the problem is that there are so many ways to do it wrong. Consider these examples from the Error Message Hall of Shame:

Unnecessary error messages

Incorrect:

This example from Windows XP might be the worst error message ever. It indicates that a program couldn’t launch because Windows itself is in the process of shutting down. There is nothing the user can do about this or even wants to do about this (the user chose to shut Windows down, after all). And by displaying this error message, Windows prevents itself from shutting down!

The problem: The error message itself is the problem. Aside from dismissing the error message, there is nothing for users to do.

Leading cause: Reporting all error cases, regardless of users’ goals or point of view.

Recommended alternative: Don’t report errors that users don’t care about.

«Success» error messages

Incorrect:

This error message resulted from the user choosing not to restart Windows immediately after program removal. The program removal was successful from the user’s point of view.

The problem: There’s no error from the user’s point of view. Aside from dismissing the error message, there is nothing for users to do.

Leading cause: The task completed successfully from the user’s point of view, but failed from the uninstall program’s point of view.

Recommended alternative: Don’t report errors for conditions that users consider acceptable.

Completely useless error messages

Incorrect:

Users learn that there was an error, but have no idea what the error was or what to do about it. And no, it’s not OK!

The problem: The error message doesn’t give a specific problem and there is nothing users can do about it.

Leading cause: Most likely, the program has poor error handling.

Recommended alternative: Design good error handling into the program.

Incomprehensible error messages

Incorrect:

In this example, the problem statement is clear, but the supplemental explanation is utterly baffling.

The problem: The problem statement or solution is incomprehensible.

Leading cause: Explaining the problem from the code’s point of view instead of the user’s.

Recommended alternative: Write error message text that your target users can easily understand. Provide solutions that users can actually perform. Design your program’s error message experience don’t have programmers compose error messages on the spot.

Error messages that overcommunicate

Incorrect:

In this example, the error message apparently attempts to explain every troubleshooting step.

The problem: Too much information.

Leading cause: Giving too many details or trying to explain a complicated troubleshooting process within an error message.

Recommended alternative: Avoid unnecessary details. Also, avoid troubleshooters. If a troubleshooter is necessary, focus on the most likely solutions and explain the remainder by linking to the appropriate topic in Help.

Unnecessarily harsh error messages

Incorrect:

The program’s inability to find an object hardly sounds catastrophic. And assuming it is catastrophic, why is OK the response?

The problem: The program’s tone is unnecessarily harsh or dramatic.

Leading cause: The problem is due to a bug that appears catastrophic from the program’s point of view.

Recommended alternative: Choose language carefully based on the user’s point of view.

Error messages that blame users

Incorrect:

Why make users feel like a criminal?

The problem: The error message is phrased in a way that accuses the user of making an error.

Leading cause: Insensitive phrasing that focuses on the user’s behavior instead of the problem.

Recommended alternative: Focus on the problem, not the user action that led to the problem, using the passive voice as necessary.

Silly error messages

Incorrect:

In this example, the problem statement is quite ironic and no solutions are provided.

The problem: Error message statements that are silly or non-sequitors.

Leading cause: Creating error messages without paying attention to their context.

Recommended alternative: Have your error messages crafted and reviewed by a writer. Consider the context and the user’s state of mind when reviewing the errors.

Programmer error messages

Incorrect:

In this example, the error message indicates that there is a bug in the program. This error message has meaning only to the programmer.

The problem: Messages intended to help the program’s developers find bugs are left in the release version of the program. These error messages have no meaning or value to users.

Leading cause: Programmers using normal UI to make messages to themselves.

Recommended alternative: Developers must conditionally compile all such messages so that they are automatically removed from the release version of a product. Don’t waste time trying to make errors like this comprehensible to users because their only audience is the programmers.

Poorly presented error messages

Incorrect:

This example has many common presentation mistakes.

The problem: Getting all the details wrong in the error message presentation.

Leading cause: Not knowing and applying the error message guidelines. Not using writers and editors to create and review the error messages.

The nature of error handling is such that many of these mistakes are very easy to make. It’s disturbing to realize that most error messages could be nominees for the Hall of Shame.

The characteristics of good error messages

In contrast to the previous bad examples, good error messages have:

• A problem. States that a problem occurred.
• A cause. Explains why the problem occurred.
• A solution. Provides a solution so that users can fix the problem.

Additionally, good error messages are presented in a way that is:

• Relevant. The message presents a problem that users care about.
• Actionable. Users should either perform an action or change their behavior as the result of the message.
• User-centered. The message describes the problem in terms of target user actions or goals, not in terms of what the code is unhappy with.
• Brief. The message is as short as possible, but no shorter.
• Clear. The message uses plain language so that the target users can easily understand problem and solution.
• Specific. The message describes the problem using specific language, giving specific names, locations, and values of the objects involved.
• Courteous. Users shouldn’t be blamed or made to feel stupid.
• Rare. Displayed infrequently. Frequently displayed error messages are a sign of bad design.

By designing your error handling experience to have these characteristics, you can keep your program’s error messages out of the Error Message Hall of Shame.

Avoiding unnecessary error messages

Often the best error message is no error message. Many errors can be avoided through better design, and there are often better alternatives to error messages. It’s usually better to prevent an error than to report one.

The most obvious error messages to avoid are those that aren’t actionable. If users are likely to dismiss the message without doing or changing anything, omit the error message.

Some error messages can be eliminated because they aren’t problems from the user’s point of view. For example, suppose the user tried to delete a file that is already in the process of being deleted. While this might be an unexpected case from the code’s point of view, users don’t consider this an error because their desired outcome is achieved.

Incorrect:

This error message should be eliminated because the action was successful from the user’s point of view.

For another example, suppose the user explicitly cancels a task. For the user’s point of view, the following condition isn’t an error.

Incorrect:

This error message should also be eliminated because the action was successful from the user’s point of view.

Sometimes error messages can be eliminated by focusing on users’ goals instead of the technology. In doing so, reconsider what an error really is. Is the problem with the user’s goals, or with your program’s ability to satisfy them? If the user’s action makes sense in the real world, it should make sense in software too.

For example, suppose within an e-commerce program a user tries to find a product using search, but the literal search query has no matches and the desired product is out of stock. Technically, this is an error, but instead of giving an error message, the program could:

• Continue to search for products that most closely match the query.
• If the search has obvious mistakes, automatically recommend a corrected query.
• Automatically handle common problems such as misspellings, alternative spellings, and mismatching pluralization and verb cases.
• Indicate when the product will be in stock.

As long as the user’s request is reasonable, a well designed e-commerce program should return reasonable results not errors.

Another great way to avoid error messages is by preventing problems in the first place. You can prevent errors by:

• Using constrained controls. Use controls that are constrained to valid values. Controls like lists, sliders, check boxes, radio buttons, and date and time pickers are constrained to valid values, whereas text boxes are often not and may require error messages. However, you can constrain text boxes to accept only certain characters and accept a maximum number of characters.
• Using constrained interactions. For drag operations, allow users to drop only on valid targets.
• Using disabled controls and menu items. Disable controls and menu items when users can easily deduce why the control or menu item is disabled.
• Providing good default values. Users are less likely to make input errors if they can accept the default values. Even if users decide to change the value, the default value lets users know the expected input format.
• Making things just work. Users are less likely to make mistakes if the tasks are unnecessary or performed automatically for them. Or if users make small mistakes but their intention is clear, the problem is fixed automatically. For example, you can automatically correct minor formatting problems.

Providing necessary error messages

Sometimes you really do need to provide an error message. Users make mistakes, networks and devices stop working, objects can’t be found or modified, tasks can’t be completed, and programs have bugs. Ideally, these problems would happen less often for example, we can design our software to prevent many types of user mistakes but it isn’t realistic to prevent all of these problems. And when one of these problems does happen, a helpful error message gets users back on their feet quickly.

A common belief is that error messages are the worst user experience and should be avoided at all costs, but it is more accurate to say that user confusion is the worst experience and should be avoided at all costs. Sometimes that cost is a helpful error message.

Consider disabled controls. Most of the time, it is obvious why a control is disabled, so disabling the control is a great way to avoid an error message. However, what if the reason a control is disabled isn’t obvious? The user can’t proceed and there is no feedback to determine the problem. Now the user is stuck and either has to deduce the problem or get technical support. In such cases, it’s much better to leave the control enabled and give a helpful error message instead.

Incorrect:

Why is the Next button disabled here? Better to leave it enabled and avoid user confusion by giving a helpful error message.

If you aren’t sure whether you should give an error message, start by composing the error message that you might give. If users are likely either to perform an action or to change their behavior as a result, provide the error message. By contrast, if users are likely to dismiss the message without doing or changing anything, omit the error message.

Designing for good error handling

While crafting good error message text can be challenging, sometimes it is impossible without good error handling support from the program. Consider this error message:

Incorrect:

Chances are, the problem really is unknown because the program’s error handling support is lacking.

While it’s possible that this is a very poorly written error message, it more likely reflects the lack of good error handling by the underlying code there is no specific information known about the problem.

In order to create specific, actionable, user-centered error messages, your program’s error handling code must provide specific, high-level error information:

• Each problem should have a unique error code assigned.
• If a problem has several causes, the program should determine the specific cause whenever possible.
• If the problem has parameters, the parameters must be maintained.
• Low-level problems must be handled at a sufficiently high level so that the error message can be presented from the user’s point of view.

Good error messages aren’t just a UI problem, they are a software design problem. A good error message experience isn’t something that can be tacked on later.

Troubleshooting (and how to avoid it)

Troubleshooting results when a problem with several different causes is reported with a single error message.

Incorrect:

Correct:

Troubleshooting results when several problems are reported with a single error message.

In the following example, an item couldn’t be moved because it was already moved or deleted, or access was denied. If the program can easily determine the cause, why put the burden on the user to determine the specific cause?

Incorrect:

Well, which is it? Now the user has to troubleshoot.

The program can determine if access was denied, so this problem should be reported with a specific error message.

Correct:

With a specific cause, no troubleshooting is required.

Use messages with multiple causes only when the specific cause cannot be determined. In this example, it would be difficult for the program to determine if the item was moved or deleted, so a single error message with multiple causes might be used here. However, it’s unlikely that users are going to care if, for example, they couldn’t move a deleted file. For these causes, the error message isn’t even necessary.

Handling unknown errors

In some cases, you genuinely won’t know the problem, cause, or the solution. If it would be unwise to suppress the error, it is better to be up front about the lack of information than to present problems, causes, or solutions that might not be right.

For example, if your program has an unhandled exception, the following error message is suitable:

If you can’t suppress an unknown error, it is better to be up front about the lack of information.

On the other hand, do provide specific, actionable information if it is likely to be helpful most of the time.

This error message is suitable for an unknown error if network connectivity is usually the problem.

Determine the appropriate message type

Some issues can be presented as an error, warning, or information, depending on the emphasis and phrasing. For example, suppose a Web page cannot load an unsigned ActiveX control based on the current Windows Internet Explorer configuration:

• Error. «This page cannot load an unsigned ActiveX control.» (Phrased as an existing problem.)
• Warning. «This page might not behave as expected because Windows Internet Explorer isn’t configured to load unsigned ActiveX controls.» or «Allow this page to install an unsigned ActiveX Control? Doing so from untrusted sources may harm your computer.» (Both phrased as conditions that may cause future problems.)
• Information. «You have configured Windows Internet Explorer to block unsigned ActiveX controls.» (Phrased as a statement of fact.)

To determine the appropriate message type, focus on the most important aspect of the issue that users need to know or act upon. Typically, if an issue blocks the user from proceeding, you should present it as an error; if the user can proceed, present it as a warning. Craft the main instruction or other corresponding text based on that focus, then choose an icon (standard or otherwise) that matches the text. The main instruction text and icons should always match.

Error message presentation

Most error messages in Windows programs are presented using modal dialog boxes (as are most examples in this article), but there are other options:

• In-place
• Balloons
• Notifications
• Notification area icons
• Status bars
• Log files (for errors targeted at IT professionals)

Putting error messages in modal dialog boxes has the benefit of demanding the user’s immediate attention and acknowledgement. However, this is also their primary drawback if that attention isn’t necessary.

Do you really need to interrupt users so that they can click the Close button? If not, consider alternatives to using a modal dialog box.

Modal dialogs are a great choice when the user must acknowledge the problem immediately before continuing, but often a poor choice otherwise. Generally, you should prefer to use the lightest weight presentation that does the job well.

Avoid overcommunicating

Generally, users don’t read, they scan. The more text there is, the harder the text is to scan, and the more likely users won’t read the text at all. As a result, it is important to reduce the text down to its essentials, and use progressive disclosure and Help links when necessary to provide additional information.

There are many extreme examples, but let’s look at one more typical. The following example has most of the attributes of a good error message, but its text isn’t concise and requires motivation to read.

Incorrect:

This example is a good error message, but it overcommunicates.

What is all this text really saying? Something like this:

Correct:

This error message has essentially the same information, but is far more concise.

By using Help to provide the details, this error message has an inverted pyramid style of presentation.

For more guidelines and examples on overcommunicating, see User Interface Text.

If you do only eight things

1. Design your program for error handling.
2. Don’t give unnecessary error messages.
3. Avoid user confusion by giving necessary error messages.
4. Make sure the error message gives a problem, cause, and solution.
5. Make sure the error message is relevant, actionable, brief, clear, specific, courteous, and rare.
6. Design error messages from the user’s point of view, not the program’s point of view.
7. Avoid involving the user in troubleshooting use a different error message for each detectable cause.
8. Use the lightest weight presentation method that does the job well.

Usage patterns

Error messages have several usage patterns:

Label	Value
System problems The operating system, hardware device, network, or program has failed or is not in the state required to perform a task.	Many system problems can be solved by the user: Device problems can be solved by turning the device on, reconnecting the device, and inserting media. Network problems can be solved by checking the physical network connect, and running Network diagnose and repair. Program problems can be solved by changing program options or restarting the program. In this example, the program can’t find a camera to perform a user task. In this example, a feature required to perform a task needs to be turned on.
File problems A file or folder required for a task initiated by the user was not found, is already in use, or doesn’t have the expected format.	In this example, the file or folder can’t be deleted because it wasn’t found. In this example, the program doesn’t support the given file format.
Security problems The user doesn’t have permission to access a resource, or sufficient privilege to perform a task initiated by the user.	In this example, the user doesn’t have permission to access a resource. In this example, the user doesn’t have the privilege to perform a task.
Task problems There is a specific problem performing a task initiated by the user (other than a system, file not found, file format, or security problem).	In this example, the Clipboard data can’t be pasted into Paint. In this example, the user can’t install a software upgrade.
User input problems The user entered a value that is incorrect or inconsistent with other user input.	In this example, the user entered an incorrect time value. In this example, user input is not in the correct format.

Guidelines

Presentation

• Use task dialogs whenever appropriate to achieve a consistent look and layout. Task dialogs require Windows Vista or later, so they aren’t suitable for earlier versions of Windows. If you must use a message box, separate the main instruction from the supplemental instruction with two line breaks.

User input errors

• Whenever possible, prevent or reduce user input errors by:
  • Using controls that are constrained to valid values.
  • Disabling controls and menu items when clicking would result in error, as long as it’s obvious why the control or menu item is disabled.
  • Providing good default values.

Incorrect:

In this example, an unconstrained text box is used for constrained input. Use a slider instead.

• Use modeless error handling (in-place errors or balloons) for contextual user input problems.
• Use balloons for non-critical, single-point user input problems detected while in a text box or immediately after a text box loses focus.Balloons don’t require available screen space or the dynamic layout that is required to display in-place messages. Display only a single balloon at a time. Because the problem isn’t critical, no error icon is necessary. Balloons go away when clicked, when the problem is resolved, or after a timeout.

In this example, a balloon indicates an input problem while still in the control.

• Use in-place errors for delayed error detection, usually errors found by clicking a commit button. (Don’t use in-place errors for settings that are immediately committed.) There can be multiple in-place errors at a time. Use normal text and a 16×16 pixel error icon, placing them directly next to the problem whenever possible. In-place errors don’t go away unless the user commits and no other errors are found.

In this example, an in-place error is used for an error found by clicking the commit button.

• Use modal error handling (task dialogs or message boxes) for all other problems, including errors that involve multiple controls or are non-contextual or non-input errors found by clicking a commit button.
• When a user input problem is reported, set input focus to the first control with the incorrect data. Scroll the control into view if necessary. If the control is a text box, select the entire contents. It should always be obvious what the error message is referring to.
• Don’t clear incorrect input. Instead, leave it so that the user can see and correct the problem without starting over.
  • Exception: Clear incorrect password and PIN text boxes because users can’t correct masked input effectively.

Troubleshooting

• Avoid creating troubleshooting problems. Don’t rely on a single error message to report a problem with several different detectable causes.
• Use a different error message (typically a different supplemental instruction) for each detectable cause. For example, if a file cannot be opened for several reasons, provide a separate supplemental instruction for each reason.
• Use a message with multiple causes only when the specific cause can’t be determined. In this case, present the solutions in order of likelihood of fixing the problem. Doing so helps users solve the problem more efficiently.

Icons

Modal error message dialogs don’t have title bar icons. Title bar icons are used as a visual distinction between primary windows and secondary windows.

Use an error icon. Exceptions:

If the error is a user input problem displayed using a modal dialog box or balloon, don’t use an icon. Doing so is counter to the encouraging tone of Windows. However, in-place error messages should use a small error icon (16×16 pixel) to clearly identify them as error messages.

In these examples, user input problems don’t need error icons.

In this example, an in-place error message needs a small error icon to clearly identify it as an error message.

If the problem is for a feature that has an icon (and not a user input problem), you can use the feature icon with an error overlay. If you do this, also use the feature name as the error’s subject.

In this example, the feature icon has an error overlay, and the feature is the subject of the error.

Don’t use warning icons for errors. This is often done to make the presentation feel less severe. Errors aren’t warnings.

Incorrect:

In this example, a warning icon is incorrectly used to make the error feel less severe.

For more guidelines and examples, see Standard Icons.

Progressive disclosure

• Use a Show/Hide details progressive disclosure button to hide advanced or detailed information in an error message. Doing so simplifies the error message for typical usage. Don’t hide needed information, because users might not find it.

In this example, the progressive disclosure button helps users drill down to more detail if they want it, or simplify the UI if they don’t.

• Don’t use Show/Hide details unless there really is more detail. Don’t just restate the existing information in a more verbose format.
• Don’t use Show/Hide details to show Help information. Use Help links instead.

Don’t show this message again

• If an error message needs this option, reconsider the error and its frequency. If it has all the characteristics of a good error (relevant, actionable, and infrequent), it shouldn’t make sense for users to suppress it.

For more guidelines, see Dialog Boxes.

Default values

• Select the safest, least destructive, or most secure response to be the default. If safety isn’t a factor, select the most likely or convenient command.

• Design error messages to avoid the need for Help. Ordinarily users shouldn’t have to read external text to understand and solve the problem, unless the solution requires several steps.
• Make sure the Help content is relevant and helpful. It shouldn’t be a verbose restatement of the error message rather, it should contain useful information that is beyond the scope of the error message, such as ways to avoid the problem in the future. Don’t provide a Help link just because you can.
• Use specific, concise, relevant Help links to access Help content. Don’t use command buttons or progressive disclosure for this purpose.
• For error messages that you can’t make specific and actionable, consider providing links to online Help content. By doing so, you can provide users with additional information that you can update after the program is released.

For more guidelines, see Help.

Error codes

• For error messages that you can’t make specific and actionable or they benefit from Help, consider also providing error codes. Users often use these error codes to search the Internet for additional information.
• Always provide a text description of the problem and solution. Don’t depend just on the error code for this purpose.

Incorrect:

In this example, an error code is used as a substitute for a solution text.

• Assign a unique error code for each different cause. Doing so avoids troubleshooting.
• Choose error codes that are easily searchable on the Internet. If you use 32-bit codes, use a hexadecimal representation with a leading «0x» and uppercase characters.

Correct:

Incorrect:

• Use Show/Hide details to display error codes. Phrase as Error code: .

In this example, an error code is used to supplement an error message that can benefit from further information.

Sound

• Don’t accompany error messages with a sound effect or beep. Doing so is jarring and unnecessary.
  • Exception: Play the Critical Stop sound effect if the problem is critical to the operation of the computer, and the user must take immediate action to prevent serious consequences.

General

• Remove redundant text. Look for it in titles, main instructions, supplemental instructions, command links, and commit buttons. Generally, leave full text in instructions and interactive controls, and remove any redundancy from the other places.
• Use user-centered explanations. Describe the problem in terms of user actions or goals, not in terms of what the software is unhappy with. Use language that the target users understand and use. Avoid technical jargon.

Incorrect:

Correct:

In these examples, the correct version speaks the user’s language whereas the incorrect version is overly technical.

• Don’t use the following words:
  • Error, failure (use problem instead)
  • Failed to (use unable to instead)
  • Illegal, invalid, bad (use incorrect instead)
  • Abort, kill, terminate (use stop instead)
  • Catastrophic, fatal (use serious instead)

These terms are unnecessary and contrary to the encouraging tone of Windows. When used correctly, the error icon sufficiently communicates that there is a problem.

Incorrect:

Correct:

In the incorrect example, the terms «catastrophic» and «failure» are unnecessary.

• Don’t use phrasing that blames the user or implies user error. Avoid using you and your in the phrasing. While the active voice is generally preferred, use the passive voice when the user is the subject and might feel blamed for the error if the active voice were used.

Incorrect:

Correct:

The incorrect example blames the user by using the active voice.

• Be specific. Avoid vague wording, such as syntax error and illegal operation. Provide specific names, locations, and values of the objects involved.

Incorrect:

Value out of range.

Character is invalid.

Device not available.

These problems would be much easier to solve with specific names, locations, and values.

• Don’t give possibly unlikely problems, causes, or solutions in an attempt to be specific. Don’t provide a problem, cause, or solution unless it is likely to be right. For example, it is better to say An unknown error occurred than something that is likely to be inaccurate.
• Avoid the word «please,» except in situations in which the user is asked to do something inconvenient (such as waiting) or the software is to blame for the situation.

Correct:

Please wait while Windows copies the files to your computer.

• Use the word «sorry» only in error messages that result in serious problems for the user (for example, data loss or inability to use the computer). Don’t apologize if the issue occurred during the normal functioning of the program (for example, if the user needs to wait for a network connection to be found).

Correct:

We’re sorry, but Fabrikam Backup detected an unrecoverable problem and was shut down to protect files on your computer.

• Refer to products using their short names. Don’t use full product names or trademark symbols. Don’t include the company name unless users associate the company name with the product. Don’t include program version numbers.

Incorrect:

Correct:

In the incorrect example, full product names and trademark symbols are used.

• Use double quotation marks around object names. Doing so makes the text easier to parse and avoids potentially embarrassing statements.
  • Exception: Fully qualified file paths, URLs, and domain names don’t need to be in double quotation marks.

Correct:

In this example, the error message would be confusing if the object name weren’t in quotation marks.

• Avoid starting sentences with object names. Doing so is often difficult to parse.
• Don’t use exclamation marks or words with all capital letters. Exclamation marks and capital letters make it feel like you are shouting at the user.

For more guidelines and examples, see Style and Tone.

Titles

• Use the title to identify the command or feature from which the error originated. Exceptions:
  • If an error is displayed by many different commands, consider using the program name instead.
  • If that title would be redundant or confusing with the main instruction, use the program name instead.
• Don’t use the title to explain or summarize the problem that’s the purpose of the main instruction.

Incorrect:

In this example, the title is being incorrectly used to explain the problem.

• Use title-style capitalization, without ending punctuation.

Main instructions

• Use the main instruction to describe the problem in clear, plain, specific language.
• Be concise use only a single, complete sentence. Pare the main instruction down to the essential information. You can leave the subject implicit if it is your program or the user. Include the reason for the problem if you can do so concisely. If you must explain anything more, use a supplemental instruction.

Incorrect:

In this example, the entire error message is put in the main instruction, making it hard to read.

• Be specific if there are objects involved, give their names.
• Avoid putting full file paths and URLs in the main instruction. Rather, use a short name (such as the file name) and put the full name (such as the file path) in the supplemental instruction. However, you can put a single full file path or URL in the main instruction if the error message doesn’t otherwise need a supplemental instruction.

In this example, only the file name is in the main instruction. The full path is in the supplemental instruction.

• Don’t give the full file path and URL at all if it’s obvious from the context.

In this example, the user is renaming a file from Windows Explorer. In this case, the full file path isn’t needed because it’s obvious from the context.

• Use present tense whenever possible.
• Use sentence-style capitalization.
• Don’t include final periods if the instruction is a statement. If the instruction is a question, include a final question mark.

Main instruction templates

While there are no strict rules for phrasing, try using the following main instruction templates whenever possible:

• [optional subject name] can’t [perform action]
• [optional subject name] can’t [perform action] because [reason]
• [optional subject name] can’t [perform action] to «[object name]»
• [optional subject name] can’t [perform action] to «[object name]» because [reason]
• There is not enough [resource] to [perform action]
• [Subject name] doesn’t have a [object name] required for [purpose]
• [Device or setting] is turned off so that [undesired results]
• [Device or setting] isn’t [available | found | turned on | enabled]
• «[object name]» is currently unavailable
• The user name or password is incorrect
• You don’t have permission to access «[object name]»
• You don’t have privilege to [perform action]
• [program name] has experienced a serious problem and must close immediately

Of course, make changes as needed for the main instruction to be grammatically correct and comply with the main instruction guidelines.

Supplemental instructions

• Use the supplemental instruction to:
  • Give additional details about the problem.
  • Explain the cause of the problem.
  • List steps the user can take to fix the problem.
  • Provide measures to prevent the problem from reoccurring.
• Whenever possible, propose a practical, helpful solution so users can fix the problem. However, make sure the proposed solution is likely to solve the problem. Don’t waste users’ time by suggesting possible, but improbable, solutions.

Incorrect:

In this example, while the problem and its recommended solution are possible, they are very unlikely.

• If the problem is an incorrect value that the user entered, use the supplemental instruction to explain the correct values. Users shouldn’t have to determine this information from another source.
• Don’t provide a solution if it can be trivially deduced from the problem statement.

In this example, no supplemental instruction is necessary; the solution can be trivially deduced from the problem statement.

• If the solution has multiple steps, present the steps in the order in which they should be completed. However, avoid multi-step solutions because users have difficulty remembering more than two or three simple steps. If more steps are required, refer to the appropriate Help topic.
• Keep supplemental instructions concise. Provide only what users need to know. Omit unnecessary details. Aim for a maximum of three sentences of moderate length.
• To avoid mistakes while users perform instructions, put the results before the action.

Correct:

To restart Windows, click OK.

Incorrect:

Click OK to restart Windows.

In the incorrect example, users are more likely to click OK by accident.

• Don’t recommend contacting an administrator unless doing so is among the most likely solutions to the problem. Reserve such solutions for problems that really can only be solved by an administrator.

Incorrect:

In this example, most likely the problem is with the user’s network connection, so it’s not worth contacting an administrator.

• Don’t recommend contacting technical support. The option to contact technical support to solve a problem is always available, and doesn’t need to be promoted through error messages. Instead, focus on writing helpful error messages so that users can solve problems without contacting technical support.

Incorrect:

In this example, the error message incorrectly recommends contacting technical support.

• Use complete sentences, sentence-style capitalization, and ending punctuation.

Commit buttons

• If the error message provides command buttons or command links that solve the problem, follow their respective guidelines in Dialog Boxes.
• If the program must terminate as a result of the error, provide an Exit program button. To avoid confusion, don’t use Close for this purpose.
• Otherwise, provide a Close button. Don’t use OK for error messages, because this wording implies that problems are OK.
  • Exception: Use OK if your error reporting mechanism has fixed labels (as with the MessageBox API.)

Documentation

When referring to errors:

• Refer to errors by their main instruction. If the main instruction is long or detailed, summarize it.
• If necessary, you may refer to an error message dialog box as a message. Refer to as an error message only in programming and other technical documentation.
• When possible, format the text using bold. Otherwise, put the text in quotation marks only if required to prevent confusion.

Example: If you receive a There is no CD disc in the drive message, insert a new CD disc in the drive and try again.

Источник

Номер Ошибка Решение 1 Ошибка регистрации пациента для свидетельства […] Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус» 2 Не найден CDA-документ Повторить процедуру формирования и подписания ЭД 3 CertificateType certificateType, Decimal certificateId, String certificateIdString, Int32 maxTimeoutMs, ProcessingContext processingContext Не заполнен / некорректно заполнен раздел «Профессиональное образование» или «Сертификаты» регистра кадров.
Необходимо проверить корректность введения данных в разделе «Регистр кадров» (данные подтягиваются из модуля «Регистр медицинских работников»). Профессиональное образование и сертификаты 4

Ошибка при формирование ЭД свидетельства о смерти:

System.Exception: Ошибка регистрации пациента для свидетельства #11732280240: {«Message»:[«Неправильный идентификатор системы»]}

at CdaGetter.Middleware.GetCdaMiddleware.GetCdaAsyncCore

Неправильный идентификатор системы / Отсутствует связь с МИС.
Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус», указав OID организации и код мединфо. 5

Exception EOleException in module p8561vcl.bpl at 0046E539.

Параметр задан неверно.

Некорректно заданы настройки криптопровайдера или установлена не поддерживаемая версия.
Если на ПК установлен Крипто-Про и VipNet CSP, то в VipNet CSP в меню «Дополнительно» снять галочку с опции «Поддержка работы VipNet CSP через Microsoft CryptoAPI» 2.) Если VipNet CSP отсутсвует, переустановить Крипто-Про. 6 Данные документа идентичны переданным ранее Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус» с указанием, какие именно изменения вносились в свидетельство. 7 Ожидание CDA по свидетельству продлилось больше 30000. Системная ошибка Нетрики. Повторить процедуру формирования и подписания ЭД 8 HTTP request failed Техническая ошибка на стороне сервисов. Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус».  9 System.Exception: Ошибка при формировании блока сведений по сотруднику […] Расхождение данных ФРМО / ФРМР и данных в модулях «Паспорт ЛПУ», «Регистр медицинских работников» — раздел «Регистром кадров».
Необходимо проверить по сотруднику данные по исполнениям должностей. Данные в «Регистре медицинских работников, раздел Регистр кадров» должны полностью совпадать с данными в продуктивном контуре ФРМР (Дата начала, Должность, Структурное подразделение, кол-во ставок, Тип занятости). После приведения данных в соответствие, повторно сформировать электронный документ. 10

Поле «State» заполнено некорректно.

DeadInfo.AddressDto.State»,»Поле «State» заполнено некорректно.

Ошибка связана с некорректным заполнением Адреса, (регион. улица).
Необходимо заполнять адрес согласно справочнику «Географические понятия» 11 The element type «hr» must be terminated by the matching end-tag «</hr>». Ошибка связана с несоответствием данных в ФРМР и регистром кадров (регистром медицинских работников).
Необходимо актуализировать информацию на ФРМР. Данные должны соответствовать регистру медицинских работников. После — повторить процедуру создания электронного документа и его подписание. 12 Сертификаты недоступны. В окне выбора сертификатов нет доступных записей. Не выполнены рекомендации, указанные в руководстве пользователя по пункту «Подготовительный этап работ».
Необходимо выполнить пункт 3.1.3.1 «Подготовительный этап работ» руководства пользователя 13 Object reference not set to an instance of an object. Несоответствие данных в ФРМО и ФРМР с «Регистром медицинских работников», «Паспорт ЛПУ».
Необходимо актуализировать информацию на ФРМР и ФРМО. Данные должны соответствовать модулю «Регистр медицинских работников» и «Паспорт ЛПУ». После — повторить процедуру создания электронного документа и его подписание. 14 Документ заблокирован другим пользователем Ошибка говорит о том, что документ открыт у других пользователей. Необходимо закрыть документ под другими пользователями и повторить процедуру формирования и подписания ЭД. 15 В сертификате отсутствует атрибут «OGRN» При использовании ЭЦП руководителя не обнаружен реквизит «ОГРН». Необходимо подписывать ЭЦП, содержащей указанный атрибут.  16 Поле «Middle Name» заполнено некорректно. Recipient.Person.HumanName.MiddleName Во вкладке «Получатель» некорректно заполнено поле «Фамилия», «Имя» или «Отчество». Необходимо внести корректировки на вкладке «Получатель»: некорректно заполнено поле «Фамилия», «Имя» или «Отчество». 17 Ошибка поиска должности (…) сотрудника […] на дату XX.XX.XXXX в регистре кадров» У сотрудника (…) на XX.XX.XXXX нет действующей должности ‘….’. Необходимо указать в свидетельстве одну из должностей, которая действует на эту дату.  18

System.Exception: Подпись врача не найдена.

at CdaSender.Middleware.SendMiddleware.GetRequestDataAsync(Decimal rn, CertificateType certificateTy

Ошибка возникает по причине некорректного указания должности для сотрудников, заполненных по полям «Лицо, заполнившее свидетельство», «Лицо, выдавшее свидетельство», «Лицо, установившее смерть».
Вкладка «Медицинский персонал». Для сотрудников, указанных в полях «Лицо, заполнившее свидетельство», «Лицо, выдавшее свидетельство», «Лицо, установившее смерть» запрещено указывать должности, относящиеся к блоку «Руководители медицинских организаций». Необходимо внести корректировки по полю «Должность». ФЛК на стороне подсистемы «Демография» будет доработан в ближайшее время. 19 RUNTIME_ERROR; Message: Непредвиденная ошибка Подобного рода ошибки возникают в тот момент, когда ЭД был отправлен в ФРЭМД, но при этом федеральный сервис был в этот момент не доступен. При этом в сервисе Нетрики происходит автоматическая переотправка таких документов. Со стороны пользователя дополнительных действий не требуется. Необходимо дождаться статуса документа, когда он либо будет «Принят ЕГИСЗ», либо «Ошибка ЕГИСЗ» (с описание корректной причины отказа в принятии документа). Если в «Журнале сообщений» нет записей, необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус». 20 Неверный СНИЛС = ошибка в вычислении контрольной суммы Не пройдена проверка на соблюдение контрольной суммы указанного СНИЛС. Необходимо произвести корректировки в поле «СНИЛС». ФЛК на стороне подсистемы «Демография» будет доработан в ближайшее время. 21 Неверный формат SOAP-сообщения ответа поставщика (unmarshalling): The element type «hr» must be terminated by the matching end-tag «</hr>». Отсутствие доступа к федеральному сервису в момент отправки документа. Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка автоматически со стороны интеграционного шлюза. 22 Поле Id Document Type заполнено некорректно. Recipient.Person.DocumentsDto[1].IdDocumentType

Некорректно указан тип документа, удостоверяющего личность. Необходимо внести корректировки по полю «Тип документа, удостоверяющего личность».

23 Поле ‘Birth Area’ заполнено некорректно. NbInfo.BirthArea. Не заполнено поле «Местность» блока «Адреса». Документ «Свидетельство о рождении», на вкладке «Даные ребенка» необходимо указать «Местность».  24 [«Указан некорректный номер Медицинского свидетельства о рождении. Допустимо использовать значение, соответствующее регулярному выражению ^[2]{1}[0-9]{8,9}$. DocN»] С 1.03.2022 введена новая нумерация медицинских свидетельств о рождении. В связи с этим свидетельства со старыми номерами, не отправленные до 1 марта, невозможно выгрузить в региональную систему Нетрика. Выгружайте свидетельства, выданные после 1 марта. 25 Ошибка отправки:
<s:Envelope xmlns:s=»http://schemas.xmlsoap.org/soap/envelope/»><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring xml:lang=»ru-RU»>Создатель этой ошибки не указал Reason.</faultstring><detail><RequestFault xmlns=»http://schemas.datacontract.org/2004/07/N3.EMK.Dto.Common» xmlns:i=»http://www.w3.org/2001/XMLSchema-instance»><PropertyName/><Message>Произошла техническая ошибка</Message><ErrorCode>99</ErrorCode><Errors/></RequestFault></detail></s:Fault></s:Body></s:Envelope>

Техническая ошибка. Необходимо заново нажать на документе ПКМ — Электронный документ — Сформировать и отправить ЭД — ОК.

При этом статус документа должен быть автоматически сменён на «Передача данных в ЕГИСЗ»

26 Code: NOT_UNIQUE_PROVIDED_ID; Message: Документ с идентификатором ‘…’ уже зарегистрирован Данный документ был успешно зарегистрированы в РЭМД, но статус от федерального сервиса не пришел. При этом в сервисе Нетрики происходит автоматическая переотправка таких документов. Со стороны пользователя дополнительных действий не требуется. Необходимо дождаться статуса документа, когда он либо будет «Принят ЕГИСЗ», либо «Ошибка ЕГИСЗ» (с описание корректной причины отказа в принятии документа). Если в «Журнале сообщений» нет записей, необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус». 27 Code: PERSON_POST_IN_FRMR_MISMATCH; Message: Указанная должность сотрудника не соответствует занимаемой им должности в организации […] на дату создания документа […] по данным ФРМР. Сотрудник с индексом

Расхождение данных на продуктивном контуре ФРМР и данных в подсистеме «Демография» по блоку «Медперсонал».

Необходимо проверить сведения по сотрудникам в разделе «Регистр кадров»:

• Исполнение должности. Должность работника МО

Данные в «Регистре кадров» должны полностью совпадать с данными в продуктивном контуре ФРМР на дату выдачи свидетельства. После приведения данных в соответствие, повторно сформировать электронный документ. 

28 PERSON_CARD_NOT_FOUND; Message: По данным REST-службы ФРМР на дату создания документа […] отсутствует личное дело сотрудника с индексом [0]

Расхождение данных на продуктивном контуре ФРМР и данных в подсистеме «Демография» по блоку «Медперсонал».

Необходимо проверить сведения по сотрудникам в разделе «Регистр кадров»:

• ФИО
• Дата рождения
• Пол
• СНИЛС
• Исполнение должности. Должность работника МО
• Исполнение должности. Структурное подразделение
• Профессиональное образование. Специальность

Данные в «Регистре кадров» должны полностью совпадать с данными в продуктивном контуре ФРМР на дату выдачи свидетельства. После приведения данных в соответствие, повторно сформировать электронный документ. 

29 System.Exception: Ошибка регистрации пациента для свидетельства #: {«Message»:[«Rest Request to MPI return status code BadRequest. Content: {«resourceType»:»OperationOutcome»,»issue»:[{«severity»:»error»,»code»:»value»,»details»:{«coding»:[{«system»:»http://hl7.org/fhir/issue-type»,»code»:»value»}]},»diagnostics»:»Parameter Patient.BirthDate content is invalid»},{«severity»:»error»,»diagnostics»:»Parameter Patient.BirthDate content is invalid»}]}»]} Ошибка может возникает в случае, если личность пациента не установлена.
Выгрузка свидетельств для пациентов с неустановленной личностью в данный момент не поддерживается федеральной системой. В случае, если личность пациента не установлена, свидетельство не подлежит выгрузке в формате электронного документа. 30 System.Exception: Ошибка регистрации пациента для свидетельства #: {«Message»:[«Rest Request to MPI return status code Forbidden. Content: {«resourceType»:»OperationOutcome»,»issue»:[{«severity»:»error»,»code»:»forbidden»,»details»:{«coding»:[{«system»:»http://hl7.org/fhir/issue-type»,»code»:»forbidden»}]},»diagnostics»:»Unauthorized»},{«severity»:»error»,»diagnostics»:»Unauthorized»}]}»]} Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус» 31 Code: FILE_WAS_NOT_SENT; Message: РМИС/МИС не передала файл ЭМД Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 32 callback:
Code: GET_DOCUMENT_FILE_ERROR; Message: Сервис предоставляющей ИС не доступенjava.lang.IllegalArgumentException: Невозможно вызвать операцию getDocumentFile callback-сервиса РМИС версии 3.0. Адрес сервиса: https://ips.rosminzdrav.ru/644401e0fba9a. Ошибка: connect timed out. Тип ошибки: SocketTimeoutException Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 33 callback:
Доступ к сервису временно запрещён — для системы, соответствующей идентификатору c4e06f16-7ff5-4610-b664-04180756f025, превышен лимит запросов к сервису Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 34 В случае возникновения ошибки: callback: Code: VALIDATION_ERROR; Message: Ошибки валидации в ФРМСС:[code: MSSCERT, description: Внутренняя ошибка сервиса ФРМСС, уникальный идентификатор ошибки: aa21f6cc-55ed-4e15-a25c-931d71d48004]. Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 35 Code: PATIENT_CREATION_ERROR; Message: Внутренняя ошибка ГИП при создании пациента Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 36 Code: INTERNAL_ERROR; Message: Внутренняя ошибка системы Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 37 System.Exception: Error while executing SQL non query: ORA-20103: Недопустимо изменение параметра ID_PATIENT Если по свидетельству был получен CDA-документ, а после были внесены правки по пациенту (умершему), то для повторного переформирования электронного документа необходимо обратиться к сотрудникам МИАЦ для внесения изменений в Регистре пациентов (Нетрика), после изменений данных в их системе, переформировывать CDA в Демографии и заново повторить отправку документа 38 System.Exception: Ошибка отправки свидетельства #**********: {«Message»:[«Идентификатор пациента в запросе не совпадает с ранее зарегистрированным»]} Если по свидетельству был получен CDA-документ, а после были внесены правки по пациенту (умершему), то для повторного переформирования электронного документа необходимо обратиться к сотрудникам МИАЦ для внесения изменений в Регистре пациентов (Нетрика), после изменений данных в их системе, переформировывать CDA в Демографии и заново повторить отправку документа 39 Удаление свидетельства Для удаления свидетельства необходимо обратиться к сотруднику МИАЦ, Клевко Василию Александровичу. 40 Удалить электронный документ

Необходимо оформить Заявка.docx и направить в МИАЦ.

Для получения локального идентификатора необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус»

41 Ошибка отправки свидетельства #********: {«Message»:[«Поле «Death Area» заполнено некорректно. DeadInfo.DeathArea»]} Не заполнено поле «Местность». Документ «Свидетельство о смерти», на вкладке «Адреса» необходимо указать «Местность». 42 Code: VALIDATION_ERROR; Message: Ошибки валидации в ФРМСС:[code: DUPLICATE, description: Свидетельство с номером [ ] и серией [ ] уже зарегистрировано]

Ответ от СТП ЕГИСЗ:

Данная проблема известна, работы по ее устранению уже ведутся.
Ошибка будет устранена в одном из ближайших релизов. После обновления системы будет опубликована соответствующая новость на портале СТП ЕГИСЗ (https://support.egisz.rosminzdrav.ru)
Следите за новостями.
Приносим извинения за доставленные неудобства.

43 System.Exception: Ошибка отправки свидетельства #*********: {«Message»:[«Поле ‘Registry Area’ заполнено некорректно. MotherInfo.RegistryArea»]}

Свидетельство о рождении, закладки: данные матери — не заполнено поле «Местность».

По обязательности заполнения поля «Местность» был сделан запрос в СТП ЕГИСЗ (#886057), на который получен ответ:

«В Руководстве по реализации СЭМД «Медицинское свидетельство о рождении» Редакция 4, действительно, указание местности регистрации матери является обязательным.»

44 Поле ‘Mother Occupation’ заполнено некорректно. MotherInfo.MotherOccupation Некорректно заполнено поле «Занятость матери». Недопустимо использовать значение «Неизвестно».  45 Ошибка при обмене данными: SocketException: Обрыв канала (Write failed) Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 46 The request channel timed out attempting to send after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 47 Превышено время ожидания ответа поставщика Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 48 Ошибки валидации в ФРМСС:[code: MSSCERT, description: Введенные данные не удовлетворяют ограничению [frmss.cert.ch4cert8receiver_fio] уникальный идентификатор ошибки: b9281110-4040-4bee-ba90-c0a0e22d3af1]

Заявка в СТП ЕГИСЗ #860376.

Ответ от СТП ЕГИСЗ:

Уважаемый пользователь.

Данная проблема известна, работы по ее устранению уже ведутся. К сожалению, сроки решения проблемы не определены. Необходимо ожидать.

49 Code: RUNTIME_ERROR; Message: Internal error Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 50 Не удалось построить цепочку сертификатов до Головного УЦ(сертификат организации выдан не аккредитованным УЦ или один из сертификатов цепочки не действителен) Для регистрации документа в РЭМД необходимо, чтобы подпись МО и сотрудников действовала на дату создания ЭМД и дату регистрации ЭМД в РЭМД.

В данном случае тип ошибки определяется ответом от УЦ, мы уже работаем над исправлением отправляемого кода ошибки.

Документы, согласно пп 140, необходимо регистрировать в РЭМД в течении 1 суток с момента их создания.
Однако, согласно ФЗ-63 и подчиненным актам ФСБ — при проверки подписи, подпись должна быть действительна, то есть если врач подписал ЭМД, далее у него истекла подпись и далее направить документ на регистрацию, то такой документ зарегистрирован не будет, так как проверка подписи, осуществляемая сертифицированными криптографическими средствами, выполнена не будет.

51 CryptoProSigner timeout exception Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза 52 System.ArgumentException: Документ с таким NRN отсутвует в базе Вкладка Медперсонал, блок Руководитель, должен быть указан руководитель организации. 53 В регистре найдено медицинское свидетельство о рождении с указанными серией и номером. Необходимо исправить серию и номер Документ «Сведения о бумажном МСР» зарегистрирован в РЭМД. Необходимо направить запрос в техническую поддержку ООО ЦИТ «Южный Парус» с перечнем номеров свидетельств для смены статусов в подсистеме Демография. 54

Сертификат сотрудника не действителен на дату создания документа /

Сертификат МО не действителен на дату создания документа

Необходимо проверить действие исполнения должности, указанной в свидетельстве у всех сотрудников с вкладки Медперсонал.  Если условие соблюдено, направить список номеров свидетельств в СТП Парус. 55 Данные документа с IdDocumentType = 14 различаются в MotherInfo и Recipient. Свидетельство о рождении, вкладка «Данные матери» поле код подразделения не должно быть пустым. 56 Доступ к сервису временно запрещён — для системы, соответствующей идентификатору ***********************, превышен лимит запросов к сервису Со стороны пользователя действий не требуется,по документу будет произведена повторная отправка в ФРЭМД автоматически со стороны интеграционного шлюза. 57 Message»:[«Поле ‘Issued Date’ не может быть пустым. DeadInfo.Person.DocumentsDto[0].IssuedDate»] Отсутствует дата выдачи документа, удостоверяющего личность. 

Периодически владельцы мобильных телефонов сталкиваются с проблемами при отправке SMS-сообщений (невозможность отправки, появление определенных кодов ошибки). Чтобы помочь посетителям нашего сайта, столкнувшимся с вышеупомянутыми проблемами, мы подготовили тематическую статью, в которой рассмотрим наиболее распространенные причины появления ошибок при отправке SMS и представим способы их устранения. Для удобства читателей блога сначала расскажем о частых причинах, объясняемых внешними факторами, а далее рассмотрим причины, напрямую связанные с неверными настройками или с неисправностью телефона.

Содержание

1. Почему не отправляются СМС с телефона: основные причины появления ошибок при отправке СМС
2. Почему не отправляются SMS с телефона: другие причины появления ошибок при отправке SMS

Почему не отправляются СМС с телефона: основные причины появления ошибок при отправке СМС

Если вы столкнулись с невозможностью отправки СМС, то в первую очередь нужно проверить самые очевидные возможные причины такого явления. В числе прочего рекомендуем выполнить следующие действия:

1. Проверка баланса. Убедитесь, что у вас достаточно денег для отправки SMS. Если вы используете специальный пакет услуг, включающий отправку определенного количества SMS, то удостоверьтесь, что не потратили все предварительно оплаченные SMS.
2. Проверка сигнала. Убедитесь в достаточной стабильности сигнала от используемой мобильной сети. Для этого проверьте уровень сигнала на дисплее мобильного телефона (обычно отображается в виде делений в верхней части экрана) и попробуйте осуществить звонок. Если сигнала нет или он очень слабый, то перезагрузите телефон. При неудаче – поищите место с устойчивым сигналом и уже оттуда отправьте SMS.
3. Проверка корректности набираемого номера. Удостоверьтесь, что номер получателя сообщения указан верно. Проще всего это сделать, осуществив звонок на этот номер и убедившись в наличии соединения.
4. Устранение кратковременного сбоя в работе смартфона. Иногда SMS не отправляется из-за сбоя в работе телефона или установленной ОС. В этом случае следует перезагрузить телефон и попробовать отправить SMS еще раз.

Также ошибка отправки SMS может возникать в ситуации, когда номер отправителя находится в черном списке получателя. Для проверки версии надо проверить, отправляются ли SMS на номера других абонентов из списка контактов.

Почему не отправляются SMS с телефона: другие причины появления ошибок при отправке SMS

Если вышеприведенные действия не помогли решить вопрос с отправкой SMS-сообщений, то стоит проверить некоторые настройки телефона, а также исключить влияние причин технического характера. В частности, стоит обратить внимание на такие параметры:

1. Настройка SMS-центра. На телефонах Android все SMS отправляются через специальный сервис мобильного оператора. Обычно нужные настройки прописываются по умолчанию (при установке SIM-карты), но иногда их приходится прописывать вручную. Для этого надо зайти в приложение «Сообщения», перейти в «Настройки», а затем последовательно нажать на «Дополнительно», «SMS», «SMS-центр» и указать номер. Узнать нужный номер можно у представителей мобильного оператора (прямо на сайте оператора или позвонив на горячую линию организации). В качестве альтернативного решения можно запросить у оператора услугу по автоматической настройке параметров отправки SMS. При проблемах отправки SMS с iPhone зачастую достаточно зайти в настройки сообщений и активировать опцию «Отправка как SMS».
2. Очистка кэша приложений или памяти смартфона. Иногда SMS не отправляется из-за неочищенного кэша приложения «Сообщения» или отсутствия свободного пространства на телефоне. В первом случае достаточно зайти в настройки приложения (через основные настройки телефона) и почистить кэш. Во втором – надо удалить мусор с телефона, а затем попробовать заново отправить SMS.
3. Отключение конфликтного софта. Если на телефоне установлены сторонние программы, предназначенные для оптимизации функционала совершения звонков или отправки SMS, то стоит на время отключить эти приложения. Возможно, после этого отправку сообщения получится выполнить без каких-либо проблем.

Также ошибки при отправке SMS иногда возникают из-за плохого состояния SIM-карты (в этом случае надо менять SIM-карту) или по причине сбоев в работе сети мобильного оператора (надо дождаться нормализации работы сети). В обеих ситуациях остается ждать или (как альтернатива) обращаться к оператору для получения объяснений и сопутствующих рекомендаций.

Если приведенные советы не помогут, то целесообразно обратиться в сервисный центр. Мастера помогут исправить ситуацию. А если это невозможно по техническим причинам, то понадобится заменить SIM-карту или смартфон – в зависимости от источника проблемы и особенностей ее решения. Другие способы решения вопроса представлены на видео. Рекомендуем к ознакомлению.

Мы можем показать ошибки двумя способами, не используя окно предупреждения. Синтаксис: узел. textContent = «Некоторое сообщение об ошибке» // Для привлечения внимания node.

В JavaScript свойство error message используется для установки или возврата сообщения об ошибке.Синтаксис:errorObj.message.Возвращаемое значение:Возвращает строку,представляющую подробности ошибки.

Не существует фиксированных способов отображения ошибок в HTML-формах, но распространенными способами отображения сообщений об ошибках являются: Просто добавьте атрибуты проверки в поля HTML-формы, и браузер автоматически покажет ошибки. Например, <input type=»text» required/>

Типы ошибок

Последнее обновление: 30.08.2021

В блоке catch мы можем получить информацию об ошибке, которая представляет объект. Все ошибки, которые генерируются интерретатором JavaScript,
предоставляют объект типа Error, который имеет ряд свойств:

• message: сообщение об ошибке

• name: тип ошибки

Стоит отметить, что отдельные браузеры поддерживают еще ряд свойств, но их поведение в зависимости от браузера может отличаться:

• fileName: название файла с кодом JavaScript, где произошла ошибка

• lineNumber: строка в файле, где произошла ошибка

• columnNumber: столбец в строке, где произошла ошибка

• stack: стек ошибки

Получим данные ошибки, например, при вызове несуществующей функции:

try{
	callSomeFunc();
}
catch(error){
	console.log("Тип ошибки:", error.name);
	console.log("Ошибка:", error.message);
}

Консольный вывод:

Тип ошибки: ReferenceError
Ошибка: callSomeFunc is not defined

Типы ошибок

Выше мы рассмотрели, что генерируемая интерпретатором ошибка представляет тип Error, однако при вызове несуществующей функции
генерируется ошибка типа ReferenceError. Дело в том, что тип Error представляет общий тип ошибок. В то же время есть конкретные типы ошибок для определенных ситуаций:

• EvalError: представляет ошибку, которая генерируется при выполнении глобальной функции eval()

• RangeError: ошибка генерируется, если параметр или переменная, представляют число, которое находится вне некотоого допустимого диапазона

• ReferenceError: ошибка генерируется при обращении к несуществующей ссылке

• SyntaxError: представляет ошибку синтаксиса

• TypeError: ошибка генерируется, если значение переменной или параметра представляют некорректный тип или пр попытке изменить значение, которое нельзя изменять

• URIError: ошибка генерируется при передаче функциям encodeURI() и decodeURI() некорректных значений

• AggregateError: предоставляет ошибку, которая объединяет несколько возникших ошибок

Например, при попытке присвоить константе второй раз значение, генерируется ошибка TypeError:

try{
	const num = 9;
	num = 7;
}
catch(error){
	console.log(error.name);		// TypeError
	console.log(error.message);		// Assignment to constant variable.
}

Применение типов ошибок

При генерации ошибок мы можем использовать встроенные типы ошибок. Например:

class Person{
 
    constructor(name, age){
		if(age < 0) throw new Error("Возраст должен быть положительным");
        this.name = name;
        this.age = age;
    }
	print(){ console.log(`Name: ${this.name}  Age: ${this.age}`);}
}
	
try{
	const tom = new Person("Tom", -45);
	tom.print();
}
catch(error){	
	console.log(error.message);	// Возраст должен быть положительным
}

Здесь конструктор класса Person принимает значения для имени и возаста человека. Если передан отрицательный возраст, то генерируем ошибку в виде объекта Error. В качестве параметра в
конструктор Error передается сообщение об ошибке:

if(age < 0) throw new Error("Возраст должен быть положительным");

В итоге при обработке исключения в блоке catch мы сможем получить переданное сообщение об ошибке.

Все остальные типы ошибок в качестве первого параметра в конструкторе также принимают сообщение об ошибке. Так, сгенерируем несколько типов ошибок:

class Person{
 
    constructor(pName, pAge){
		
		const age = parseInt(pAge);
		if(isNaN(age))	throw new TypeError("Возраст должен представлять число");
		if(age < 0 || age > 120) throw new RangeError("Возраст должен быть больше 0 и меньше 120");
        this.name = pName;
        this.age = age;
    }
	print(){ console.log(`Name: ${this.name}  Age: ${this.age}`);}
}

Поскольку для возраста можно ередатьне только число, но и вообще какое угодно значение, то вначале мы пытаемся преобразовать это значение в число с помощью
функции parseInt():

const age = parseInt(pAge);
if(isNaN(age))	throw new TypeError("Возраст должен представлять число");

Далее с помощью функции isNaN(age) проверяем, является полученное число числом. Если age — НЕ число, то данная функция возвращает true. Поэтому
генерируется ошибка типа TypeError.

Затем проверяем, что полученное число входит в допустимый диапазон. Если же не входит, генерируем ошибку типа RangeError:

if(age < 0 || age > 120) throw new RangeError("Возраст должен быть больше 0 и меньше 120");

Проверим генерацию исключений:

try{
	const tom = new Person("Tom", -45);
}
catch(error){	
	console.log(error.message);	// Возраст должен быть больше 0 и меньше 120
}

try{
	const bob = new Person("Bob", "bla bla");
}
catch(error){	
	console.log(error.message);	// Возраст должен представлять число
}

try{
	const sam = new Person("Sam", 23);
	sam.print();	// Name: Sam  Age: 23
}
catch(error){	
	console.log(error.message);
}

Консольный вывод:

Возраст должен быть больше 0 и меньше 120
Возраст должен представлять число
Name: Sam  Age: 23

Обработка нескольких типов ошибок

При выполнении одного и то же кода могут генерироваться ошибки разных типов. И иногда бывает необходимо разграничить обработку разных типов.
В этом случае мы можем проверять тип возникшей ошибки. Например, пример выше с классом Person:

class Person{
 
    constructor(pName, pAge){
		
		const age = parseInt(pAge);
		if(isNaN(age))	throw new TypeError("Возраст должен представлять число");
		if(age < 0 || age > 120) throw new RangeError("Возраст должен быть больше 0 и меньше 120");
        this.name = pName;
        this.age = age;
    }
	print(){ console.log(`Name: ${this.name}  Age: ${this.age}`);}
}
	
try{
	const tom = new Person("Tom", -45);
	const bob = new Person("Bob", "bla bla");
}
catch(error){	
	if (error instanceof TypeError) {
		console.log("Некорректный тип данных.");
	} else if (error instanceof RangeError) {
		console.log("Недопустимое значение");
	}
	console.log(error.message);
}

Создание своих типов ошибок

Мы не ограничены встроенными только встроенными типами ошибок и при необходимости можем создавать свои типы ошибок, предназначеные для каких-то конкретных ситуаций.
Например:

class PersonError extends Error {
  constructor(value, ...params) {
    // остальные параметры передаем в конструктор базового класса
    super(...params)
    this.name = "PersonError"
    this.argument = value;
  }
}

class Person{
 
    constructor(pName, pAge){
		
		const age = parseInt(pAge);
		if(isNaN(age))	throw new PersonError(pAge, "Возраст должен представлять число");
		if(age < 0 || age > 120) throw new PersonError(pAge, "Возраст должен быть больше 0 и меньше 120");
        this.name = pName;
        this.age = age;
    }
	print(){ console.log(`Name: ${this.name}  Age: ${this.age}`);}
}
	
try{
	//const tom = new Person("Tom", -45);
	const bob = new Person("Bob", "bla bla");
}
catch(error){	
	if (error instanceof PersonError) {
		console.log("Ошибка типа Person. Некорректное значение:", error.argument);
	}
	console.log(error.message);
}

Консольный вывод

Ошибка типа Person. Некорректное значение: bla bla
Возраст должен представлять число

Для представления ошибки класса Person здесь определен тип PersonError, который наследуется от класса Error:

class PersonError extends Error {
  constructor(value, ...params) {
    // остальные параметры передаем в конструктор базового класса
    super(...params)
    this.name = "PersonError"
    this.argument = value;
  }
}

В конструкторе мы определяем дополнительное свойство — argument. Оно будет хранить значение, которое вызвало ошибку. С помощью параметра value конструктора
получаем это значение. Кроме того, переопреляем имя типа с помощью свойства this.name.

В классе Person используем этот тип, передавая в конструктор PersonError соответствующие значения:

if(isNaN(age))	throw new PersonError(pAge, "Возраст должен представлять число");
if(age < 0 || age > 120) throw new PersonError(pAge, "Возраст должен быть больше 0 и меньше 120");

Затем при обработки исключения мы можем проверить тип, и если он представляет класс PersonError, то обратиться к его свойству argument:

catch(error){	
	if (error instanceof PersonError) {
		console.log("Ошибка типа Person. Некорректное значение:", error.argument);
	}
	console.log(error.message);
}

Сообщение об ошибке информация отображается , когда непредвиденная проблема возникает, как правило , на компьютере или другом устройстве. В современных операционных системах с графическим интерфейсом сообщения об ошибках часто отображаются с помощью диалоговых окон. Сообщения об ошибках используются, когда требуется вмешательство пользователя, чтобы указать, что желаемая операция не удалась, или чтобы передать важные предупреждения (например, предупреждение пользователя компьютера о том, что ему почти не хватает места на жестком диске ). Сообщения об ошибках широко распространены в вычислительной технике и являются частью каждой операционной системы или аппаратного устройства компьютера . Правильный дизайн сообщений об ошибках — важная тема в юзабилити и других областях взаимодействия человека с компьютером .

Общие сообщения об ошибках

Современные пользователи компьютеров часто видят следующие сообщения об ошибках:

В доступе отказано

Эта ошибка возникает, если у пользователя нет прав на доступ к файлу, или если он был заблокирован какой-либо программой или пользователем.

Устройство не готово

Эта ошибка чаще всего возникает, когда в дисководе нет гибкого диска (или неисправного диска), и система пытается выполнить задачи, связанные с этим диском.

Файл не найден

Соответствующий файл мог быть поврежден, перемещен, удален или ошибка могла быть вызвана ошибкой. В качестве альтернативы, файл может просто не существовать, или пользователь неправильно ввел его имя. Чаще используется в интерфейсах командной строки, чем в графических пользовательских интерфейсах, где файлы отображаются в виде значков и пользователи не вводят имена файлов.

Мало места на диске

Эта ошибка возникает, когда жесткий диск (почти) заполнен. Чтобы исправить это, пользователь должен закрыть некоторые программы (чтобы освободить использование файлов подкачки ) и удалить некоторые файлы (обычно временные файлы или другие файлы после их резервного копирования) или получить жесткий диск большего размера.

Недостаточно памяти

Эта ошибка возникает, когда системе не хватает памяти или она пытается загрузить файл слишком большого размера для хранения в ОЗУ . Чтобы исправить это, нужно закрыть некоторые программы или установить больше памяти.

[название программы] перестала работать.

Это сообщение отображается в Microsoft Windows 10, когда программа вызывает общий сбой защиты или ошибку неверной страницы .

Примечательные сообщения об ошибках

• Прервать, повторить попытку, сбой? — Печально известное сбивающее с толку сообщение об ошибке в MS-DOS.

  

  Пример сообщения об ошибке .vbs-скрипта

• Неверная команда или имя файла — еще одно общеизвестно распространенное и сбивающее с толку сообщение об ошибке в MS-DOS.
• Синий экран смерти — на Microsoft Windows и ReactOS операционных систем, этот экран не появляется , когда для Windows или ReactOS больше не может работать из — за серьезной ошибки. Это примерно аналогично панике ядра в Linux , Unix или macOS .
• Красный экран смерти — такой же , как синий экран смерти, но он красный.
• Не могу продлить — сообщение об ошибке от Acorn DFS . DFS хранит файлы в нефрагментированном непрерывном дисковом пространстве, эта ошибка возникает при попытке расширить открытый файл с произвольным доступом в пространство, которое уже занято другим файлом.
• Guru Meditation — сообщение об ошибке от Commodore Amiga , примерно аналогичное панике ядра или BSOD, также принятое более новыми продуктами, такими как VirtualBox .
• HTTP 404 — ошибка «файл не найден» в Интернете , обычно возникающая из-за ссылки на страницу, которая была перемещена или удалена, или из-за ошибочного ввода URL-адреса.
• lp0 on fire — предупреждение Unix о том, что принтер может быть «в огне».
• Не пишущая машинка — сообщение об ошибке Unix, которое сбивает с толку из-за устаревшего использования слова пишущая машинка, и которое иногда выводится, когда природа ошибки кажется совершенно другой.
• ПИСЬМО ЗАГРУЗКИ ПК — ошибка на нескольких лазерных принтерах HP, из-за которой пользователю просто предлагалось добавить бумагу размера «Letter» запутанным способом.
• ОШИБКА СИНТАКСИСА — встречается во многих компьютерных системах, когда полученные инструкции находятся в формате, который они не понимают.
• HTTP 504 — ошибка, обнаруженная во всемирной паутине, о том, что истекло время ожидания шлюза в интернет-ссылке.
• Ошибка 1603 — ошибка, указывающая на то, что проблема возникает во время установки компьютерной программы , особенно эта ошибка возникает в компьютерных системах Windows .
• <имя приложения> остановлено — сообщение об ошибке, которое обычно встречается на устройствах Android , в котором говорится, что текущее запущенное приложение неожиданно перестает работать или дает сбой.
• Успех — одно из сообщений об ошибке (в данном случае POSIX ), которое возникает, когда программа обнаруживает состояние ошибки, но фактическая процедура печати сообщения об ошибке использует библиотеку C для печати ошибки, сообщенной операционной системой (в данном случае, errno.h ), в то время как базовые системные вызовы завершились успешно и не сообщают об ошибках (в данном случае errno == 0). Это форма небрежной обработки ошибок, которая особенно сбивает с толку пользователей.
• [Ошибка времени ожидания подключения Mac] — Ошибка возникает в системах Mac, когда для подключения к беспроводным сетям требуется больше времени.

Неудачные питомцы

С появлением сервисов Web 2.0, таких как Twitter , сообщения об ошибках конечных пользователей, такие как HTTP 404 и HTTP 500, начали отображаться с причудливыми символами, называемыми Fail Pets или Error Mascot. Термин «Fail Pet» был придуман или, по крайней мере, впервые использован в печати инженером Mozilla Фредом Венцелем в сообщении в своем блоге под названием «Почему Википедии может понадобиться Fail-Pet — и почему Mozilla нет». Доктор Шон Ринтел утверждает, что сообщения об ошибках — это важный стратегический момент в узнаваемости бренда и лояльности к нему. Неудачные питомцы интересны маркетологам, потому что они могут привести к узнаваемости бренда (особенно через заработанные СМИ ). «Однако то же самое признание несет в себе опасность выявления сбоев в обслуживании». Самым известным провальным питомцем является Fail Whale от Twitter (см. « Сбои в работе сервиса Twitter» ). К другим питомцам-неудачникам относятся:

• Ars Technica : Лунная акула
• FarmVille на Facebook: Грустная корова.
• GitHub : Octocat
• Google : сломанный робот
• iCloud : облако с лицом в стиле смайлика Apple System 7
• Macintosh : Грустный Mac
• Tumblr : Tumbeasts
• Twitter : Fail Whale / Twitter Robot
• YouTube : Телевизоры (на основном сайте), световая статика внутри окна видео (встроенное видео)
• Cartoon Network : BMO [Азия]: Домо
• Google Chrome : тираннозавр

Формат сообщения

Форма сообщений об ошибках зависит от операционных систем и программ.

Сообщения об ошибках на аппаратных устройствах, таких как компьютерная периферия, могут принимать форму специальных индикаторов, указывающих на состояние ошибки, краткого кода, который необходимо интерпретировать с помощью справочного листа или руководства, или посредством более подробного сообщения на дисплее.

На компьютерах сообщения об ошибках могут принимать форму текста, выводимого на консоль, или они могут быть представлены как часть графического пользовательского интерфейса . Сообщения об ошибках часто представлены в виде диалогового окна , что заставляет их вызывать следующую ошибку режима при взаимодействии с пользователем. Во многих случаях исходной ошибки можно избежать с помощью методов предотвращения ошибок. Вместо того, чтобы выдавать сообщение об ошибке, при разработке системы следовало избегать условий, вызвавших ошибку.

В то время как различные графические пользовательские интерфейсы имеют разные соглашения для отображения сообщений об ошибках, стали распространены несколько методов:

• В окне на экране появляется диалоговое окно или всплывающее сообщение , блокирующее дальнейшее взаимодействие с компьютером до тех пор, пока оно не будет подтверждено. В Mac OS X листы представляют собой форму диалогового окна, которое прикрепляется к определенному окну.
• Появляются значки уведомлений, чтобы уведомить пользователя о состоянии, не прерывая его работу. В Windows значки уведомлений отображаются на панели задач. В Mac OS X значки уведомлений могут отображаться в строке меню или принимать форму значка приложения, «подпрыгивающего» в Dock. GNOME интерфейс пользователя для систем Unix может отображать значки уведомлений в панели.
• Незначительные ошибки могут отображаться в строке состояния , небольшой части окна приложения, которая может отображать краткие сообщения для пользователя.

Три основных фактора, которые влияют на дизайн сообщений об ошибках, — это технические ограничения, объем представляемой информации и тип пользовательского ввода, который требуется.

Некоторые системы имеют технические ограничения, которые могут ограничивать объем информации, которую может содержать сообщение об ошибке. Например, принтер с шестнадцатизначным буквенно-цифровым дисплеем может одновременно отображать только очень ограниченный объем информации, поэтому ему может потребоваться отображать очень краткие сообщения об ошибках. Даже с компьютерными мониторами программист должен рассмотреть самый маленький монитор, который пользователь может разумно использовать, и убедиться, что все сообщения об ошибках умещаются на этом экране.

Характер ошибки определяет объем информации, необходимый для эффективной передачи сообщения об ошибке. Сложная проблема может потребовать более подробного сообщения об ошибке, чтобы должным образом проинформировать пользователя о проблеме.

Безопасность

При разработке сообщений об ошибках разработчики программного обеспечения должны позаботиться о том, чтобы избежать создания уязвимостей в системе безопасности. Дизайнер должен предоставить пользователю достаточно информации, чтобы принять разумное решение, но не столько информации, чтобы пользователь был ошеломлен или сбит с толку. Посторонняя информация может быть скрыта по умолчанию или размещена в отдельном месте. Сообщение об ошибке не должно раскрывать информацию, которая может быть использована взломщиком для получения информации, которую иначе получить трудно. Примерами являются системы, которые могут отображать либо «недопустимый пользователь», либо «недопустимый пароль», в зависимости от того, какой из них неверен, а также страница ошибки на веб-сервере IIS 5.0, которая предоставляет полное техническое описание ошибки, включая фрагмент исходного кода.

Смотрите также

• Диалоговое окно предупреждения
• Взаимодействие человека с компьютером
• Интерактивный дизайн
• Юзабилити
• Ошибка пользователя
• Дизайн пользовательского интерфейса
• Обработка исключений

использованная литература

внешние ссылки

• Более полезный 404 (A List Apart)
• Не смущайтесь сообщениями об ошибках (UX Matters)
• Ой! Я испортил твою жизнь. (Купер Журнал)