Преимущества утвердительного программирования
Если вы имеете в виду запросы HTTP GET, вы можете зарегистрировать фильтр глобальных запросов для короткого замыкания Authenticate запросов HTTP GET с помощью:
GlobalRequestFilters.Add((req, res, requestDto) => {
if (requestDto is Authenticate auth && req.Verb == HttpMethods.Get)
{
res.StatusCode = (int)HttpStatusCode.MethodNotAllowed;
res.EndRequest();
}
});
. также отключил GET Authenticate запросы по умолчанию (для не OAuth-провайдеров) в в этом коммите из v5.4.1 +, который теперь доступен в MyGet , его можно повторно включить с помощью: [ 118]
Plugins.Add(new AuthFeature(...) {
AllowGetAuthenticateRequests = req => true
});
6 ответов
Они также поддерживают философию быстрого отказа, объясненную в этой статье Джимом Шором.
Где некоторые люди пишут:
/*
* This can never happen
*/
Гораздо более практично писать:
assert(i != -1);
Мне нравится использовать утверждения, потому что они легко отключаются с помощью простой постоянной времени компиляции или делаются в сделать что-то еще, как подготовить отчет об ошибке. Я обычно не оставляю утверждения включенными (по крайней мере, не обычным способом) при выпуске чего-либо.
Использование их спасло меня от совершения очень глупых ошибок на компьютерах других людей ... тех смельчаков, которым нравится тестировать мою альфу код. Использование таких инструментов, как valgrind, помогает гарантировать, что я поймаю что-то ужасное перед тем, как его совершить.
Важное различие, которое следует учитывать, - это то, какие ошибки вы бы хотели зафиксировать с помощью утверждений. Я часто использую утверждения для обнаружения ошибок программирования (т. Е. Вызова метода с нулевым параметром) и другого механизма для обработки ошибок валидации (например, передача номера социального страхования неправильной длины). Для ошибки программирования, пойманной с утверждением, я хочу быстро потерпеть неудачу. На ошибку валидации я хочу отреагировать менее радикально, потому что это может быть нормально, если в данных есть ошибки (например, пользователь делает какой-то ввод данных). В этих случаях правильной обработкой может быть сообщение об ошибке обратно пользователю и продолжение работы.
Если для метода есть заданное предварительное условие для получения ненулевого параметра сообщения, то вы хотите, чтобы программа завершилась неудачей, как только предварительное условие не выполнит Hold и источник ошибки должен быть исправлен.
Я считаю, что утверждения более важны при разработке программного обеспечения, критически важного для безопасности. И, конечно, вы бы предпочли использовать утверждения, когда программное обеспечение было официально указано.
Для отличного обсуждения утверждений (и многих других тем, связанных с построением кода), посмотрите Code Complete Стива Макконнела. Он посвящает целую главу эффективному использованию утверждений.
I use them to verify that I have been supplied valid dependent class. for exmaple in constructor DI, you usually are accepting some sort of external class that you are dependent on to provide some action or service.
so you can assert(classRef !- null,"classRef cannot be null"); instead of waiting for you to pass a message to classRef and getting some other exception such as exception : access violation or something equally ambiguous that might not be immediately obvioius from looking at the code.