Сигнальный протокол в common lisp'е
Ты охуенен. И эти сигналы на первый взгляд охуенны. Но сейчас я найду причины, по которым они плохи.
Для упрощения этой задачи, можешь привести пример перехвата ошибки с последующим восстановлением.
Нет ничего идеального, иначе не было бы 100500 разных парадигм и языков. Для процедурного программирования unchecked exceptions кагбе наименее плохой вариант.
http://ideone.com/djTBth
То же, но не с вырвиглазной разметкой: http://paste.lisp.org/display/155379
Там два перезапуска используются: если значение - неведомая поебень, то skip-this-shit, если число, то store-value
Все говен и создавались большинство на коленке для поднятия ЧСВ.
Идеального тоже нет. НО программирование это инженерная дисциплина и в ней должен быть порядок.
А порядка нет. Есть куча петухов которые тянут одеяло на себя и обмазываются всякими фичами, которым цена три копейки.
Каждый мнит себя творцом, клепает по 10 языков за год и тянет ИТ в энтропию.
Either вместе с do-сахарком охуенна.
А ты хуесос.
А ты хуесос.
>Either вместе с do-сахарком охуенна.
Конечно охуенна. Просто без ду-сахарка еитхер - неюзабельное говно, а с ним - те же исключения, что и в яве.
>Either вместе с do-сахарком охуенна.
>Просто без ду-сахарка еитхер - неюзабельное говно
Э, уася, но как же монадка, either то композабелен. А твои сраные сигналы и эксепшны нет.
let it crash
/thread
Всегда нравилась эта аргументация. Ну так-то фича не плохая, но вот если убрать вон ту штуку, получится говно. Перекатывайтесь лучше в java/scala/rust/etc
Go!
съеби обратно в свой петушиный куток и гоуно своё примитивное забери
> either то композабелен
Что ты подразумеваешь под "композабелен"?
(<=<) шоле? Так тут никаких отличий от исключений.
В случае Either ошибка является полноценным значением, а не костылём, прикрученным сбоку. И, соответственно, функции, которые могут принимать/возвращать ошибку можно комбинировать так же, как и обычные функции.
ВНЕАПНО исключения - такие же обычные первоклассные объекты, которые можно так же передать в другую функцию, вернуть как значение или опять как исключение.
Никаких принципиальных отличий.
Но для этого нужно лепить
{ try { foo(); } catch (Exception e) { bar(); } baz(); }
вместо какого-нибудь
foo >>= bar >== baz
мимо
>а не костылём, прикрученным сбоку
Таким некостылём, что в хаскеле до сих пор бардак с обработкой ошибок.
И что за хуйню ты написал?
Ах, обосрался со стрелочкой. Но суть от этого не меняется.
> хаскеле до сих пор бардак
Точка. Это одна из ключевых особенностей хаскеля, к примеру, в скале с этим получше.
>(restart-case (factorial x) (skip-this-shit (&optional y) y))
Выглядит идентично try { return factorial(x); } catch(SkipThisShitException e) { return e; }
А invoke-restart выглядит идентично throw. В чем профит?
Ты не понял. Ошибка type-error отлавливается тут:[code lang=lisp]
(handler-bind ((type-error #'fix-input))
(print (factorials 1 5.2 2 3 "sasai" -1 5 6)))
[/code]
И обрабатывается функцией fix-input [code lang=lisp]
(defun fix-input (cond)
(typecase #1=(type-error-datum cond)
((integer 0) (store-value (abs #1#)))
(real (store-value (floor #1#)))
(t (invoke-restart 'skip-this-shit :skipped))))[/code], которая принимает решение о дальнейших действиях: заменить аргумент n в factorial, вызвав перезапуск store-value, или пропустить вычисления и вернуть :skipped
>А invoke-restart выглядит идентично throw.
invoke-restart вызывается выше* по стеку вызовов, throw - ниже.
>invoke-restart вызывается выше* по стеку вызовов, throw - ниже.
Эт я хуйню написал. Фактически invoke-restart тоже ниже, но фишка в том, что при обработке сигнала (type-error в нашем случае) стек вызовов не раскручивается, и обработчик вызывается в том же месте (в функции factorial, в недрах check-type) и с тем же динамическим окружением, где сигнал произошел, поэтому принимать решение о перезапусках можно выше.
В общем, try catch'ами такое сэмулировать не получится.
Ох уж эти функцианальщики. Как только выберутся за пределы своей функцианальной песочницы, так сразу беспомощные. Все мозги отсыхают, видимо. Дали тебе фвп - делай конбенаторы и канбенируй.
http://try.haxe.org/#91955
>conbenator
Это ж просто не полиморфная версия (return .)
Можно оборачивать try-except в Maybe, например:
[code]
def maybe_int(x):
try:
return Just(int(x))
except:
return Nothing
value = (
maybe_int(input())
.bind(lambda x: maybe_int(input())
.bind(lambda y: Just(x + y)))
)
[/code]
А так можно упростить себе жизнь:
[code]
def wrap_try(fn):
def inner(args):
try:
return Just(fn(args))
except:
return Nothing
maybe_int = wrap_try(int)
[/code]
[/code]
[code]
def maybe_int(x):
try:
return Just(int(x))
except:
return Nothing
value = (
maybe_int(input())
.bind(lambda x: maybe_int(input())
.bind(lambda y: Just(x + y)))
)
[/code]
А так можно упростить себе жизнь:
[code]
def wrap_try(fn):
def inner(args):
try:
return Just(fn(args))
except:
return Nothing
maybe_int = wrap_try(int)
[/code]
[/code]
мда, форматирование съехало, и return inner забыл
но думаю, суть ясна
и да, если кому не понятно — это пытон
У меня от этого кода ЗАКАТ СОЛНЦА ВРУЧНУЮ
Мне не нравятся checked exceptions, они не спасают от недостатков обычных, но при этом вынуждают писать лишние аннотации.
Мне не нравится c/go-подобный подход, он вынуждает повторять однотипные блоки возврата, а затем вынуждает высматривать их в теле процедуры. Вообще, ранний возврат мне кажется неудобным для чтения.
Мне не нравится haskell-подобный подход, он по сути является вариантом checked exceptions, только вместо throws пишем Either и прописываем возврат исключения явным образом.
В каком языке, по-вашему, исключения работают идеально?