#asp.net
#asp.net
Вопрос:
Это несколько философский вопрос. У меня есть вспомогательная библиотека на основе .net (но может быть любой платформы), которая анализирует значения строки запроса. Возьмем, к примеру, переменную, которая возвращает Int32: в моей платформе есть опция, которая указывает, является ли это значение обязательным или необязательным. Если это требуется, но не предусмотрено, платформа выдает исключение. Если оно является необязательным и не указано, оно возвращает значение null.
Теперь возник крайний случай, основанный на том, что пользователи взломали (в хорошем смысле) наши URL-адреса. Если они указывают переменную либо с неверно отформатированным Int32 («amp;ID= abc»), либо предоставляют переменную, но не указывают значение («amp;id=»), должен ли фреймворк генерировать исключение или должен возвращать значение null?
Часть меня чувствует, что недопустимые переменные или форматы должны возвращать значение null. Может быть справедливо утверждать, что даже если параметр является необязательным, неверно отформатированная строка запроса или значение все равно должны вызывать исключение.
Мысли?
Комментарии:
1. Когда вы говорите о своей структуре, вы говорите о ASP.NET или ваше собственное веб-приложение?
2. У меня есть свой собственный фреймворк.
3. Все эти искаженные URL-адреса являются результатом того, что пользователи «взламывают» вещи. Все это есть в нашей внутренней сети, и мы допускаем некоторые глубокие ссылки, поэтому взлом сам по себе не является проблемой. Но если вы собираетесь взломать URL-адрес и предоставить недопустимый int для идентификатора («amp; id= abc»), должно ли это вызывать исключение? Чем больше я думаю об этом, тем больше я думаю, что ответ на это — да.
Ответ №1:
Поскольку это философский…
Что-то вроде идентификатора, я бы согласился с Шоном, что это 404, особенно если вы думаете в терминах состояния. Объект отсутствует, поэтому не найден. Но идентификатор может не привязываться непосредственно к ресурсу во всех случаях.
Если элемент действительно необязательный, значение null допустимо. Но необязательный должен означать «если присутствует, это делает вызов более конкретным» в этом случае, и всегда должен быть запасной вариант. Я не вижу этого в ID, если только идентификатор не привязан к необязательной части страницы.
В долгосрочной перспективе, я думаю, вам следует посмотреть на бизнес-причину страницы и значение каждой переменной.
Ответ №2:
Я считаю, что если переменная является необязательной, предоставление переменной, но не указание значения эквивалентно отсутствию самой переменной. В этом случае возврат null кажется нормальным.
Однако предоставление неверно отформатированного значения должно вызвать исключение, поскольку целью было предоставить значение. В этом случае пользователь должен быть уведомлен через какой-то механизм проверки.
Ответ №3:
Исключение HttpException из 404 (не найдено). Ваша платформа веб-приложения должна знать, как перехватывать эти ошибки и перенаправлять на нужную страницу.
На самом деле это ошибка not found, поскольку ресурсы, на которые указывает идентификатор, не существуют.
Ответ №4:
Я подозреваю, что на ваш вопрос нет «правильного» ответа. Если бы я был разработчиком, использующим вашу библиотеку, я бы ожидал / надеялся, что общедоступный API включит в свои комментарии к коду описание того, как ведет себя функция, когда параметр URL содержит неверные (неправильный тип) данные.
Вы также можете создать свой общедоступный API, чтобы получить лучшее из обоих миров: .NET, похоже, во многих местах использует подход «Parse» / «TryParse». Если я вызывающий, и я хочу, чтобы функция выдавала неверные данные, я вызываю Parse() . Если я не хочу, чтобы он выдавал, я вызываю TryParse() . На мой взгляд, это хороший шаблон для вашего API.