В настоящее время я работаю над инструментом командной строки, и так как это мой первый раз, когда я разрабатываю такой инструмент, у меня есть несколько вопросов по дизайну, в первую очередь, как справиться с нелетальной ошибкой.Ошибка проектирования инструмента командной строки
Инструмент, с которым я работаю, создает основной сервер на настраиваемом порту, а затем дополнительный веб-сервер на неконфигурируемом порту. Если мы затем сделаем это снова (при использовании другого порта для основного сервера), мы, очевидно, получим ошибку привязки при попытке запустить дополнительный веб-сервер.
Поскольку это не смертельная ошибка (запуск веб-сервера необязателен), и из опыта пользовательского интерфейса мои первоначальные мысли состоят в том, чтобы распечатать ясную ошибку и продолжить работу с программой. Однако мне сказали, что с точки зрения сценария распечатайте ошибку, а затем существующая практика лучше.
Так что же лучше?
Я понимаю, что вы говорите, однако перегрузка потребителя флагами может смутить ИМХО. Итак, в таком случае, почему «безопасный» выход будет лучше четким сообщением? – jonatzin
Ну, что такое «безопасное» поведение по умолчанию при отсутствии флага, вероятно, зависит от того, если/насколько сильно наносится ущерб, если незнакомый пользователь вывел программу без флага. Я предположил «вычеркивание ошибок» как значение по умолчанию, потому что я понял, что наименьший урон может произойти, если он ошибается, и поэтому ничего не работает. – ArjunShankar
Хмммм, хорошо, хорошая точка. Спасибо за помощь! – jonatzin