VladD2,
VD>То что выдает интерпретатор Эрлэнга в качестве сообщений об ошибках назвать сообщениями об ошибках мой язык не поворачивается.
VD>Собвственно вопрос в том, есть ли что-то (патчи, хаки, ...) что позволяет увидить более менее оумысленные сообщения об ошибках?
VD>Ну, и естесвнно вопрос. Что привело к такой жути?
Надеюсь что ты не об этом (здесь имхо всё прозрачно)
./io_layer.erl:224: variable 'Insert' is unbound
а об этом
=ERROR REPORT==== 16-Oct-2006::11:16:04 ===
Error in process <0.72.0> with exit value: {undef,[{io_layer,dostart,[<0.72.0>]},{io_layer,test1,0}]}
Сообщение об ошибке (точнее, код выхода (exit reason)) — это tagged терм. Соответственно все преимущества этого подхода налицо — возможность делать паттерн-матчинг, пересылать другим процессам и т.п, короче создавать функции принимающие этот терм в качестве аргумента. Недостаток тоже на лицо — трудность восприятия. По крайней мере пока не появится навык видеть в этом терме смысл.
Весь "хак", который в данном случае нужен, это функция description(E) -> ... Честно говоря, лень её лабать, проще терм просмотреть.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>Надеюсь что ты не об этом (здесь имхо всё прозрачно) LCR>>./io_layer.erl:224: variable 'Insert' is unbound
VD>А как такое получить то? У меня что-то все второй вариант появляется.
Такое получается, когда ошибка компиляции. Страшное сообщение — когда ошибка выполнения.
LCR>>Сообщение об ошибке (точнее, код выхода (exit reason)) — это tagged терм. Соответственно все преимущества этого подхода налицо — возможность делать паттерн-матчинг, пересылать другим процессам и т.п, короче создавать функции принимающие этот терм в качестве аргумента.
VD>Зачем мне что-то делать с сообщением об ошибке? Мне нужно его прочесть и понять. Ну, еще неплохо было бы дабал-кликнув перейти к месту ошибке в исходном файле.
По сообщению об ошибке компиляции перейти можно (по крайней мере мой Емакс переходит). По сообщению времени исполнения перейти, естественно, труднее.
LCR>>Недостаток тоже на лицо — трудность восприятия. По крайней мере пока не появится навык видеть в этом терме смысл.
VD>На фиг такие навыки. Привыкая к маразму сам не заметишь как станешь маразматиком.
Теперь философия. Зачем нужно такое сообщение об ошибке? Дело в том, что одна из фишек Эрланга — это как раз обработка ошибок. Ошибок времени исполнения, разумеется. Когда вы вводите в интерпретаторе что-нибудь вроде
1=0.
происходит ошибка времени исполнения
{{badmatch,0},[{erl_eval,expr,3}]}
(В данном случае все просто. Произошла ошибка badmatch, т.е. ошибка сопоставления с образцом, 0 — это то значение, которое не было сопоставлено. Тут бы еще показать то с значение, с которым не сопоставлено, т.е. в данном случае, 1, но чего нет, того нет. Список [{erl_eval,expr,3}] — это стек вызовов, в данном случае, неглубокий.)
Идея в том, что этот терм (сообщение об ошибке + стек) можно перехватить в вашей же программе, обработать, скинуть в лог, отправить по почте — словом, обработать. И тут, согласитесь, чем больше информации, тем лучше.
Теперь об интерпретаторе. Конечно, можно было бы в интерпретаторе вместо сообщения {{badmatch,0},[{erl_eval,expr,3}]} поставить что-нибудь многословное, вежливо объясняющее, что же произошло. Но нужно ли это? Зачем вообще нужен интепретатор? Чтобы вычислить какое-нибудь выражение, вызвать функцию, и посмотреть, что будет. Вот оно нам честно и говорит, что будет. И ровно то же самое (с точностью до стека) будет и при выполнении программы. Так что всегда можно посмотреть, какая ошибка выдается при вычислении какого-либо выражения и знать, что будет при вычислении этого выражения в реальной работе, когда интерпретатора уже и рядом не будет.
Re[4]: Про сообщения об ошибках интерпретатора Эрлэнга
Здравствуйте, faulx, Вы писали:
F>По сообщению об ошибке компиляции перейти можно (по крайней мере мой Емакс переходит). По сообщению времени исполнения перейти, естественно, труднее.
Ничего естественного я тут не усматриваю. Было бы куда удобнее если можно было бы перейти и по рантйм ошибке. Темболее что язык динамически типизируемый и стало быть ошибок в приципе больше будет в рантайме чем при компиляции.
F>Теперь философия. Зачем нужно такое сообщение об ошибке? Дело в том, что одна из фишек Эрланга — это как раз обработка ошибок. Ошибок времени исполнения, разумеется. Когда вы вводите в интерпретаторе что-нибудь вроде F>
1=0.
F>происходит ошибка времени исполнения F>
F>{{badmatch,0},[{erl_eval,expr,3}]}
F>
F>(В данном случае все просто. Произошла ошибка badmatch, т.е. ошибка сопоставления с образцом, 0 — это то значение, которое не было сопоставлено. Тут бы еще показать то с значение, с которым не сопоставлено, т.е. в данном случае, 1, но чего нет, того нет. Список [{erl_eval,expr,3}] — это стек вызовов, в данном случае, неглубокий.)
Откровенно говоря я в этом сообщении вижу много лишнего "шума" (мусора) и не вижу важной информации — строки в которой произошла ошибка.
F>Идея в том, что этот терм (сообщение об ошибке + стек) можно перехватить в вашей же программе, обработать, скинуть в лог, отправить по почте — словом, обработать. И тут, согласитесь, чем больше информации, тем лучше.
Соглашусь. Но информации, а не шума. Я согласен, что структурированная информация хороша для програмной обработки. Но не согласен ее читать в качестве сообщений об ошибках. В отом же дотнете и Яве мы так же имеем объекты описывающие исключения и API для получения информации о стеке вызовов. Но! Так же мы имеем возможность в один момент превратить эту информацию в хорошо читаемый текст. Стэк трэйс разворачивается в список методов (как они вызвались) с описанием значений их параметров, а само сообщение имеет (обычно) текстовое описание проблемы. Мне кажется, что такой подход куда удобнее и (главное) человечнее.
F>Теперь об интерпретаторе. Конечно, можно было бы в интерпретаторе вместо сообщения {{badmatch,0},[{erl_eval,expr,3}]} поставить что-нибудь многословное, вежливо объясняющее, что же произошло.
Ага. Я бы только сказал не "многословное", а "легко понятное".
F> Но нужно ли это?
Очень нужно. Удобство — это одна из важнейших черт любого продукта. А уж языка программирования в первую очередь.
F> Зачем вообще нужен интепретатор?
Незнаю. Я кроме интерпретатора пакетных файлов ОС (и то редко) других не использую.
F> Чтобы вычислить какое-нибудь выражение, вызвать функцию, и посмотреть, что будет. Вот оно нам честно и говорит, что будет. И ровно то же самое (с точностью до стека) будет и при выполнении программы.
В этом-то и проблема. Если пользователю или программисту занимаещемуся отладкой вывалится такая бяка, то он будет не очень в восторге.
F> Так что всегда можно посмотреть, какая ошибка выдается при вычислении какого-либо выражения и знать, что будет при вычислении этого выражения в реальной работе, когда интерпретатора уже и рядом не будет.
Все же я не понимаю почему при этом нельзя выводить и человекочитаемое сообщение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Про сообщения об ошибках интерпретатора Эрлэнга
В принципе, можно сделать свой обработчик ошибок интерпретатора. Интерпретатор сообщает об ошибках два раза: один раз пишет сам, а другой раз прилетает сообщение от процесса error_logger. Так вот, этому error_logger-у можно поставить свой обработчик, в котором можно делать все, что угодно. Т.е., создаем модуль my_handler.erl
Теперь подключаем его: компилируем и вызваем my_handler:start(). Все, добавился еще один обработчик, и интерпретатор будет при ошибке писать то, что мы выводим в handle_event.
Здесь есть одна засада: информация об ошибке в переменной Data приходит уже в виде текстовой строки вида "Error in process <0.30.0> with exit value: {{badmatch,0},[{erl_eval,expr,3}]}". Это прописывается где-то очень глубоко. В принципе, если есть желание, можно ее распарсить, перевести и напечатать в любом удобном виде, хотя, конечно, изврат.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Надеюсь что ты не об этом (здесь имхо всё прозрачно) LCR>./io_layer.erl:224: variable 'Insert' is unbound
А как такое получить то? У меня что-то все второй вариант появляется.
LCR>Сообщение об ошибке (точнее, код выхода (exit reason)) — это tagged терм. Соответственно все преимущества этого подхода налицо — возможность делать паттерн-матчинг, пересылать другим процессам и т.п, короче создавать функции принимающие этот терм в качестве аргумента.
Зачем мне что-то делать с сообщением об ошибке? Мне нужно его прочесть и понять. Ну, еще неплохо было бы дабал-кликнув перейти к месту ошибке в исходном файле.
LCR>Недостаток тоже на лицо — трудность восприятия. По крайней мере пока не появится навык видеть в этом терме смысл.
На фиг такие навыки. Привыкая к маразму сам не заметишь как станешь маразматиком.
LCR>Весь "хак", который в данном случае нужен, это функция description(E) -> ... Честно говоря, лень её лабать, проще терм просмотреть.
Я и не хочу лабать. Вот только мне кажется, что должен был хоть кто-то попытаться решить эту проблему. Неужели никто ее так и не решил?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.