Насколько подробный сообщения об ошибках должны быть?
Если вы будете использовать jQuery, это будет легко. Я создал этот пример, используя Jquery. Надеюсь, это поможет вам.
$("input[name='travel_type']").click(function(){
if($(this).is(':checked') && $(this).val()=='1'){
$('#datepicker1').attr('disabled','disabled');
}else{
$('#datepicker1').removeAttr('disabled');
}
});<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<label> One Way
<input type="radio" name="travel_type" value="1" class="with-gap" ></label>
<label>Round Trip
<input type="radio" name="travel_type" value="2" class="with-gap" ></label>
<p><label>Date Picker <input type="date" name="datepicker" id="datepicker1"></label></p>7 ответов
Существует две возможных целевых аудитории для сообщения об ошибке, пользователя и разработчика.
Нужно обычно иметь цель сообщения пользователь.
o, какова причина проблемы.
o, почему программа не может работать вокруг проблемы
o, что пользователь может сделать для работы вокруг проблемы.
o, как сообщить о проблеме.
Если о проблеме нужно сообщить, доклад должен включать в себя как можно больше контекстной информации программы.
o имя модуля
o имя функции
o номер строки
o переменные интереса к общей области проблемы
o, возможно, даже дамп ядра.
Будьте нацелены на корректную аудиторию.
Необходимо передать то, что произошло, и каковы опции пользователя в как можно меньшем количестве слов. Чем дольше сообщение об ошибке, тем менее вероятно пользователь должен считать его. К тому же короткие сообщения об ошибках являются загадочными и бесполезными. Существует зона наилучшего восприятия с точки зрения длины, и это отличается для каждой ситуации.
Слишком короткий:
Недопустимый вход.
Слишком долго:
Введите правильно форматированный IP-адрес, такой как 192.168.0.1. IP-адрес является числом, используемым для идентификации компьютера в сети.
Просто право:
Введите допустимый IP-адрес.
Что касается чрезмерного увеличения размера кода, если немного дополнительного кода будет препятствовать тому, чтобы пользователь назвал поддержку или быть разбитым, то это - хорошие инвестиции.
Существует два типа сообщений об ошибках: Те, которые будут замечены пользователем и теми, которые это будет замечено программистом.
"Как я знаю, сможет ли пользователь понять, где они пошли не так, как надо?" Я предполагаю, что те сообщения только будут замеченными пользователем и не очень техническим, и COMPILE FAILED REASON 3 не типичное сообщение ошибки конечного пользователя. Это - что-то, что программист будет видеть (пользователь обычно не компилирует вещи).
Так, если это будет пользователь, то это будет видеть его:
- Обеспечьте короткое, "Это - сообщение об ошибке" ("операция в секунду!Что-то пошло не так!", и т.д.)
- Предоставьте маленькое обобщенное описание ошибки ("Сайт, с которым Вы пытаетесь соединиться, кажется, недоступен" / "У Вас, кажется, нет достаточного количества полномочий выполнить задачу XYZ" / и т.д.),
- Добавьте кнопку "Details>>", в случае, если Ваш пользователь, оказывается, понимает компьютеры хорошо, включая подробную информацию (отслеживание стека исключительной ситуации, код ошибки, и т.д.)
Наконец, обеспечьте, некоторые простые и понятные команды для пользователя ("Попробуйте еще раз", "Отмена", и т.д.),
Столь подробный, как они должны быть ;)
Я знаю, что это походит на умный ответ задницы, но большая часть этого зависит от Вашей целевой аудитории и типа ошибки. Для ошибок, вызванных записью недействительного пользователя, Вы могли показать им, что составляет действительный доступ. Для ошибок, которыми пользователь не может управлять, дженерик, "мы работаем над ним" сообщение типа, мог бы сделать.
Я соглашаюсь с комментариями B Jon относительно длины также.
Реальный вопрос о сообщениях об ошибках состоит в том, если они должны даже быть отображены. Много сообщений об ошибках представлено пользователю, но нет НИКАКОГО СПОСОБА для них исправить их.
Пока существует способ исправить ошибку, затем дают достаточно информации пользователю, который позволит им исправлять его самостоятельно. Если они не могут исправить его, самостоятельно там какая-либо причина сказать им техническую причину катастрофического отказа? Нет просто зарегистрируйте его в файл для поиска и устранения неисправностей позже.
Сообщения об ошибках должны быть подробно изложены, но ясные. Это может быть достигнуто путем объединения сообщений об ошибках от нескольких уровней:
Failed to save the image
Permission denied: /foo.jpg
Здесь у нас есть два уровня. Может быть больше. Сначала мы говорим большое изображение, и затем мы говорим детали. Порядок таков, что сначала нам поняли часть под большинство и затем часть, которую понимает меньше людей, но оба могут все еще быть видимы.
Дополнительно могло быть предложение фиксации.
Я допустил бы ошибку на стороне большего количества детали, но я думаю, что Вы ответили на свой собственный вопрос. Для предотвращения чрезмерного увеличения размера в коде затем предоставляют полезную информацию в коде/сообщении об ошибке, но можно предоставить больше подробную информацию в документации, возможно, или со справочными файлами или FAQ.
наличие слишком небольшой информации хуже, по-моему.
При использовании языка с богатым самоанализом или другими возможностями, журнал witht он, строка, которая привела проверку к сбою, будет полезна. Пользователь может затем передать технической поддержке или иначе получить подробную информацию, и это не чрезмерное увеличение размера дополнительного кода, но использование Вашего собственного кода для предоставления информации.