0xd34df00d
16.07.2011 13:39 Azoth_primary
Пстачик, а как делаешь ты в такой ситуации: есть функция шифрования сообщения, которая должна вернуть непустой массив при успехе. В общем, два варианта:
1. Возвращаем bool насчет успеха + out-параметр.
2. Возвращаем пустой массив в случае неуспеха, в caller'е проверяем массив на пустоту.
Как делаешь ты?
42 comments
recommend
bookmark
subscribe
я такого типа обычно вторым способом рещаю
это очень сложно ?!
Saemshit. А вот у нас с @octocat'ом дискуссия.
1 вариант налагает меньше ограничений на входные данные
второе.
Maybe [String]. А если серьёзно, я бы предпочёл второе.
Схуя?
Ты квадратные скобки зря поставил, похоже )
Я вообще зря указал там тип, надо было Maybe Message, а ты уж сам там разбирайся… :)
потому что не требует чтобы входное сообщение было непустым (потому как традиционно алгоритмы шифрования не изменяют количество байтиков в сообщении)
У вас плохое шифрование же!
Ты там rot13 чтоле юзаешь в качестве шифрования?
што.
штоблять. вы тут все упоролись штоле?
Плохая музыка, очень плохая музыка.
Возможно, ты имел ввиду, что традиционные алгоритмы шифрования сохраняют нулевой элемент.
покажи мне, позязя, традиционный алгоритм шифрования, дающий на выходе отличное по длинне от оригинального сообщение (дополнение до размера кратного размеру блока не считается)
3. бросаю исключение.
Питон-вей, хуле.
а то. Тут не заморачиваются со специальными значениями, а смело и открыто прямо вверх по стеку бросают исключение. Удобство, епт.
а if (encrypt(in, &out)) { кот; } не?
двачую
Зачем? Ну и нужда сделать out неконстантным. А Я ЛЮБЛЮ CONST.
Все скриптоёбы такие упоротые?
это то, для чего и предназначены исключения и их обработка, ёпт. Не получилось зашифровать — а поче^Wхуйн^Wисключение. Бросили его вверх, а дальше кому надо обработали.
В данном случае вполне можно обойтись без исключений. Нахуй так жить?
const string ololo = encrypt(rofl); ?
ПРИШЛО ВРЕМЯ СКОНСТРУИРОВАТЬ ОБЪЕКТ
ОБЪЕКТ САМ НЕ СКОНСТРУИРУЕТСЯ
СКОНСТРУИРУЙ ЕГО ЕЩЁ РАЗ
const string& даже в данном случае почти наверняка.
это просто ты с плюсцами не привык к тому что исключения полезны (да и я ещё не привык, хуле)
примешивая к типу нерелевантные специальные значения, ты деляешь бяку имо.
Именно поэтому из двух предложенных вариантов я предпочёл бы bool и out-аргумент.
Полезны, они в плюсцах полезны, но зачем их юзать там, где без них точно так же неплохо?
понимаешь ли, писать в стиле
if(!try_do_something(...)) { handle_error(); }
if(!proceed_further(...)) { handle_other_error(); }
if(!you_got_the_point(...)) { handle_yet_another_error(); }
— это слишком низкоуровнево и приводит к полунечитаемому коду и идиотским интерфейсам функций (впрочем, без интегрированных в синтаксис tuples, обойтись без out аргументов становится и так тяжело). Так можно, и вообще даже нужно, писать в C. Но ведь плюсцы лучше, чем C!!!
Чем тебе не нравится интерфейс функции encrypt :: String → Maybe String, с той семантикой Maybe, что функция, возможно, бросит исключение? Это ведь, как отмечает @gelraen, позволяет писать удобно, без повсеместных семантически не нагруженных перепроверок.
Тем, что у исключений в том виде, в котором они в плюсах, нет явной монадической структуры.
Не ссы, в питоне и рубях тоже, насколько я знаю
для Maybe вполне себе есть.
Причем тут maybe? Мы щас про исключения же.
а причём тут монадическая структура? ._.
Чтобы >>= был разумным.
а он и есть, для исключений. Зафейлившееся вычисление биндуется с любым в зафейлившееся.
Хм, я тогда криво выразился весьма.
Вот кстати да, Maybe было бы очень в тему.
Возвращаю что положено, но бросаю эксепшен в случае неуспеха
всё правильно делаешь.