[Erlang] Номера строк в трейсбеках

>Кто как борется?

Борется с чем? Тебе, положим, номера строк сдались. А мне, как твоему клиенту, (похрен опенсорс или нет) они нафиг не нужны. Что я с ними буду делать?

Ты пойми, ерланг он в корне отличается от "мейнстрим" языков программирования, хоть визуально имеет с ними кое-какие общие черты.

http://www.erlang.se/doc/programming_rules.shtml

"Don't clutter code for the "normal case" with code designed to handle exceptions. As far as possible you should only program the normal case. If the code for the normal case fails, your process should report the error and crash as soon as possible. Don't try to fix up the error and continue. The error should be handled in a different process"

Процессы ерлагна, они как хомячки: пожрать, потрахаться и сдохнуть.

Если нужна какая-то дополнительная информация, то можешь врубить трассировку или отладку.

Давай без фанатизма, лол. Бывает, что процессы рушатся в тех местах, где рушиться не должны. И хочется узнать, что именно к этому привело. Часто это обычная опечатка, которую в статически типизированном языке отловил бы компилятор. Отсюда вопрос: что мне сделать, чтобы получать более информативные сообщения о смерти процессов?

Во-первых, прогонять dialyzer'ом.

В рантайме - юзать дебуггер и трассировать dbg (http://www.trapexit.org/Debugging_with_Debug_Helper). Кстати, io:format тоже никто не отменял, в distel'е замена кода на лету тривиальна.

Почитай OTP Design Principles раздел 6. Плюс документацию по приложению debug, плюс описание erlang:trace.

Если код на ерланге валится у тебя в неожиданных местах, значит что-то ты делаешь не так, это тебе не C.

> Если код на ерланге валится у тебя в неожиданных местах, значит что-то ты делаешь не так, это тебе не C.

People who think that real programmers write code without bugs need to upgrade to a human brain.

Ты не прав... люди дело говорят... если ты пишешь на Erlang, то у тебя действительно программы не должны падать на ровном месте... для этого как бы и использовались те принципы, которые заложены в Erlang.

> если ты пишешь на Erlang, то у тебя действительно программы не должны падать на ровном месте...

Бугага. Кто тебе сказал про "ровное место"? Кто тебе сказал, что на Эрланге не делают ошибок?

> те принципы, которые заложены в Erlang.

Динамическая типизация, да? :D

>Кто тебе сказал, что на Эрланге не делают ошибок?

Объяснили же. Задача процесса в котором произошла ошибка - как можно скорее СДОХНУТЬ. Все остальное - заботы других процессов.

_Перед_ этим, процесс _может_, выдать какую-либо трассировочную информацию. Способов - масса, самый простой - io:format.

>Динамическая типизация, да?

Типизация, будь она хоть сто раз статической, хоть сто раз хиндли-милнеровской не предохраняет от логических ошибок.

> Задача процесса в котором произошла ошибка - как можно скорее С Задача процесса в котором произошла ошибка - как можно скорее СДОХНУТЬ

Задача процесса - выполнить свою функцию и завершиться. Если он СДОХ, он эту функцию не выполнил. Можно сколько угодно переться от того, что в Эрланге процессы могут дохнуть без последствий для исполняющей системы, но прежде всего они должны выполнять возложенные на них функции. Блин, ну лчевидные же вещи.

> Типизация, будь она хоть сто раз статической, хоть сто раз хиндли-милнеровской не предохраняет от логических ошибок.

Она не предохраняет от _всех_ логических ошибок. От многих - таки предохраняет. Ну и по словам топикстартера: "часто это обычная опечатка, которую в статически типизированном языке отловил бы компилятор".

>> если ты пишешь на Erlang, то у тебя действительно программы не должны падать на ровном месте...

>Бугага. Кто тебе сказал про "ровное место"? Кто тебе сказал, что на Эрланге не делают ошибок?

"Бывает, что процессы рушатся в тех местах, где рушиться не должны."

как это ещё толковать, как не "на ровном месте"? Мне никто не говорил что на Erlang не делают ошибок, я этого тоже не утверждал...

>> те принципы, которые заложены в Erlang.

>Динамическая типизация, да? :D

три раза хаха, не придумывай, я не об этом говорил, я про те зачатки "функционального" программирования говорил, которые есть в Erlang... вспомним хотя бы отсутсвие side effects.

>"Бывает, что процессы рушатся в тех местах, где рушиться не должны."

>как это ещё толковать, как не "на ровном месте"?

Как "непонятно, почему оно там упало".

>>> те принципы, которые заложены в Erlang.

>> Динамическая типизация, да? :D

> три раза хаха, не придумывай, я не об этом говорил,

Вот я и спрашивал, о чем именно ты говорил, а то мой libastral.so совершенно закономерно выдал ссылку на динамическую типизацию как один из принципов, заложенный в Эрланг.

>>как это ещё толковать, как не "на ровном месте"?

>Как "непонятно, почему оно там упало".

что именно тут надо было подразумевать, мы сможем выяснить, только если топикстартер приведет код, с которым у него возникли проблемы :)

> как можно скорее СДОХНУТЬ

Что ты всё "сдохнуть" да "сдохнуть"? Хочешь поговорить об этом, лол?

Если при непредвиденной смерти процесса вываливается стек вызовов - это зачем-то нужно, нет? Там есть имена модулей, имена функций, аргументы функций - но нет имени файла и номера строки, которые бы там явно не помешали. Я надеялся, что есть какой-нибудь хитрый ключик, который их включает, но фиг там.

Трассировка тоже не выход - номеров строк там один фиг она не выдаст. (Или я чёто п?)

Вставка io:format с макросом ?LINE тем более не выход - на каждую строчку его заранее не повесишь, да и не в стиле эрланга это. Можно только наугад натыкать отладочной печати вокруг предполагаемого участка с ошибкой и пытаться эту ошибку воспроизвести - что не так-то просто, если речь идёт о взаимодействии нескольких процессов.

Но с эрлангистами почему-то разговаривать о недостатках эрланга обычно бесполезно. Ответ один: Джо - бох, эрланг - его откровение, а ты быдло. Хуже только красноглазые хаскельщики и скобочники, ололо.

> отсутсвие side effects

На пересдачу.

можно последнюю просьбу? расскажи как правильно? даже на экзаменах преподаватель отвечал на этот вопрос, будь добр, снизайди и расскажи?

>Если при непредвиденной смерти процесса вываливается стек вызовов - это зачем-то нужно, нет?

Слушай, я конечно понимаю что сейчас не модно читать документацию, тем более ту, которая с компилятором идет... Но нельзя же так...

Понимаешь, у любой системы есть принципы. Если они тебе не нравятся, наверно нужно поискать другую систему.

>номеров строк там один фиг она не выдаст.

Навязчивые идеи... конечно бывают... Но все-таки - паталогия. Объясняю: тебе не нужны номера строк. Тебе нужно знать _что_ привело к крушению твоего процесса. Тебе объяснили способ получения, и хранения такой информации.

>Задача процесса - выполнить свою функцию и завершиться. Если он СДОХ, он эту функцию не выполнил.

Мы о чем говорим? Если он выполнил свою функцию, значит он выполнил, все нормально. Если по каким-то причинам он свою функцию не может выполнить, то процесс НЕ ДОЛЖЕН ГОРОДИТЬ КОСТЫЛЕЙ, по обработке и нейтрализации ошибки. Потому что: "один процесс - одна функция" и обработка ошибок туда не входит.

А дальше, все зависит от дизайна системы. Супервизор напишет в лог, перезапустит процесс, а возможно и его "соседей", а может наоборот корректно завершит соседей и завершиться сам...

Ты можешь получить трассировку, несколькими способами, в зависимости от того что и в каком объеме тебе нужно получать. Здесь сложно говорить о чем-то конкретно.

> Если по каким-то причинам он свою функцию не может выполнить, то процесс НЕ ДОЛЖЕН ГОРОДИТЬ КОСТЫЛЕЙ, по обработке и нейтрализации ошибки

А что, разве кто-то это предлагал? Не припомню. Речь шла только о том, что аварийное завершение процесса из-за программной ошибки - это плохо, и хотелось бы, чтобы исполняющая система указывала место в тексте, где произошла ошибка. Но вместо конкретного указания "сделай так, и в следе будут имена файлов и номера строк", или прямого "получить имена фалов и номера строк в следе невозможно" начинается лечение на тему "это тебе не нужно".

>"получить имена фалов и номера строк в следе невозможно"

Получить имена и номера строк в трейсах штатными средствами эрланга невозможно.

>начинается лечение на тему "это тебе не нужно"

Я хочу забивать гвозди микроскопом. Меня не интересует, что для этих целей есть молоток. Покажите мне как забивать гвозди электронным микроскопом, или скажите прямо, что забивать гвозди электронным микроскопом нельзя, и я уйду и буду на каждом углу орать какой же *sucks* этот ваш электронный микроскоп, так как им гвозди нельзя забивать.

PS: КЮ!

> Получить имена и номера строк в трейсах штатными средствами эрланга невозможно.

Не прошло и 5 часов, как мы это выяснили %)

> Я хочу забивать гвозди микроскопом.

"Всякое сравнение хромает" (с)

> Я хочу забивать гвозди микроскопом.

Macil, ты либо кре^Wне очень умный, либо неумело троллишь.

> Ты пойми, ерланг он в корне отличается от "мейнстрим" языков программирования, (...) "If the code for the normal case fails, your process should report the error and crash as soon as possible." (...) Процессы ерлагна, они как хомячки: пожрать, потрахаться и сдохнуть.

Мысленно замени "процессы ерлагна" на "процессы unix". Надо напоминать в какой книге было написано нечто _очень_ похожее на эту английскую цитату?

В корне отличается, говоришь? Может, в каком-то другом корне, не?

>Мысленно замени "процессы ерлагна" на "процессы unix".

Сравнил, называется. Сделать ерланговскую систему процессов на обычных юниксовых может быть и можно, но тут будут выпирать накладные расходы. Да и не каждое приложение себе такое может позволить. Демоны - может быть, а остальные - вряд ли.

Вот не понятно... топикстартер свалил куда-то... накидал понтов и свалил... не по-мужски это как-то :)