Oberon space
General Category => Общий раздел => Тема начата: vlad от Февраль 19, 2011, 04:59:22 am
-
Навеяно недавним просмотром ББ'ых исходников... А в чем глубокий смысл второго параметра ББ'ого ASSERT'а? Нигде таких ассертов нет :) В смысле все полезное в стэке и в номере строки, нет? :) Зачем эта лишняя сущность в языке, славящимся отсутствием всего лишнего?
-
Там по идее должна стоять строка с сообщением. Но отцы-основатели предпочитают расшифровывать числовой код.
Такое мЫшление, минимализьм, типа.
-
А зачем нам это сообщение, пусть и в виде строки, если благодаря наличию метаинформации нам среда и так выдаст подробнейший отчет что где и как произошло?
-
это для людей. прописываешь в строковых ресурсах строчку типа:
Dom.Assert.1 index or size is negative, or greater than the allowed value
и люди видят, какая ошибка произошла, потому как наличие сырцов не является обязательным.
-
Там по идее должна стоять строка с сообщением. Но отцы-основатели предпочитают расшифровывать числовой код.
Такое мЫшление, минимализьм, типа.
а на каком языке, например? такое мышление, да...
-
Дык ведь для человека, у которого нет исходников, это всё равно тарабарщина полная. А среда, благодаря метаинформации, всё равно подробный отчет предоставит. По идее оный человек после этого должен будет сохранить составной документ с отчетом и отослать его разработчику, где разраб уже проведет детальный анализ ситуации.
-
ну, ассерт это ж предусловие. если нет сырцов, то как понять, что хотел сказать автор?
и да, речь про программистов, юзеры ваще тряпы видеть не должны, такое моё мнение.
-
А в чем глубокий смысл второго параметра ББ'ого ASSERT'а?
В программе может же быть много ассертов. Лично я использую второй параметр для того чтобы однозначно идентифицировать какой из ассертов сработал. Не знаю насколько это соответствует авторскому замыслу.
-
а на каком языке, например? такое мышление, да...
Спасибо за разъяснение про строковые ресурсы.
Вообще, трогательная забота о пользователе. Одно дело, когда дается набор переводов для диалогов, меню и пр. А вот переводить все места, которые пользователь по идее не должен видеть - это "что-то особенного" :).
-
а на каком языке, например? такое мышление, да...
Спасибо за разъяснение про строковые ресурсы.
Вообще, трогательная забота о пользователе. Одно дело, когда дается набор переводов для диалогов, меню и пр. А вот переводить все места, которые пользователь по идее не должен видеть - это "что-то особенного" :).
пользователь(видимо, таки пользователь ББ) может быть разным.
когда вы предоставите критерии и методы ч0ткого отделения пользователя-хомячка(бухгалтера например), от пользователя-программиста в соседнем кубикле(или в соседней стране), тогда поговорим. Если я предоставил описание ассерта, я сделал это для программиста, и он оценит, особенно когда сырцов нет(по соображениям лицензии например).
-
А в чем глубокий смысл второго параметра ББ'ого ASSERT'а?
В программе может же быть много ассертов. Лично я использую второй параметр для того чтобы однозначно идентифицировать какой из ассертов сработал. Не знаю насколько это соответствует авторскому замыслу.
Вообще-то в С++ assert автоматом выдает имя файла и номер строки в source. И никаких дополнительных параметров.
-
Вообще-то в С++ assert автоматом выдает имя файла и номер строки в source. И никаких дополнительных параметров.
А вот сообщение консольного компилятора XDS:
#RTS: unhandled exception #199: ASSERT(FALSE, 199) И всё! Только номер и спасает ("199" в примере).
Да, и ещё. Ассерт - это всё-таки языковое средство, а не фенечка IDE. Раз язык вводит ассерты, то должен и предоставить средство для их идентификации. Второй параметр в стандартной процедуре ASSERT, на мой взгляд, оправдан.
-
А вот сообщение консольного компилятора XDS:
#RTS: unhandled exception #199: ASSERT(FALSE, 199) И всё! Только номер и спасает ("199" в примере).
Это такой тонкий стеб или реально каждый оберонщик знает что такое "199"? %)
Да, и ещё. Ассерт - это всё-таки языковое средство, а не фенечка IDE. Раз язык вводит ассерты, то должен и предоставить средство для их идентификации. Второй параметр в стандартной процедуре ASSERT, на мой взгляд, оправдан.
Дык, я ж говорю - стэк и номер строки идентифицируют намного лучше какого-то "199". По поводу модулей без исходников, но со строковыми ресурсами - да, этот параметр приобретает какой-то смысл. Но мне кажется, что в этом случае еще лучше сработал бы банальный возврат кода ошибки.
-
Это такой тонкий стеб или реально каждый оберонщик знает что такое "199"? %)
Этот код я назначил сам, и он имеет смысл только для меня, как для автора программы. От пользователя, у которого сбойнула моя программа, мне нужен только этот код и больше ничего.
По памяти, в документации на КП/BB вроде определены стандартные коды, и определён также дииапазон кодов для использования по своему усмотрению. Этими спецификациями я не пользуюсь.
Дык, я ж говорю - стэк и номер строки идентифицируют намного лучше какого-то "199".
Представьте, что у Вас много клиентов, которые пользуются различными версиями Вашей программы, и они присылают Вам отчёты, что в такой-то строчке сработал ассерт. В данной ситуации код ошибки надёжнее, потому что в различных версиях программы нумерация строк может поплыть.
Но мне кажется, что в этом случае еще лучше сработал бы банальный возврат кода ошибки.
В моём примере "199" и есть код ошибки.
-
Такой подход мне нравится!
-
Этот код я назначил сам, и он имеет смысл только для меня, как для автора программы. От пользователя, у которого сбойнула моя программа, мне нужен только этот код и больше ничего.
Неправда. Первое, что вы захотите от пользователя в случае какой-либо ошибки - это версия.
По памяти, в документации на КП/BB вроде определены стандартные коды, и определён также дииапазон кодов для использования по своему усмотрению. Этими спецификациями я не пользуюсь.
Что лишний раз показывает бессмысленность подобного рода спецификаций...
Представьте, что у Вас много клиентов, которые пользуются различными версиями Вашей программы, и они присылают Вам отчёты, что в такой-то строчке сработал ассерт. В данной ситуации код ошибки надёжнее, потому что в различных версиях программы нумерация строк может поплыть.
Коды тоже могут поплыть. Кроме того, поддерживать уникальность этих кодов в достаточной большей системе - это отдельная задача ;) Но, еще раз, версию вы захотите узнать в любом случае.
В моём примере "199" и есть код ошибки.
Не совсем. Его нельзя нормально обработать потребителю вашего модуля. Если опять говорить о варианте сторонних модулей без исходников...
-
Нет, я что-то не совсем понимаю зачем это самое целочисленное значение ассерту скармливать. Вот смотрите: сработал ASSERT, отлично. Благодаря наличию метаинформации мы точно знаем CallStack с названиями функции, мы знаем версии всех модулей, знаем структуру функции где оно сработало. В конце концов ничто не мешает также знать и вид логического условия сработавшего ассерта. Всё это мы знаем без наличия исходников.
Если ASSERT сработал на машине пользователя, то среда должна сформировать слепок состояния программы, дамп памяти, в виде пригодном для последующего анализа. Например в виде составного документа. Этот слепок отправляется к разработчику, где он уже спокойно разбирает что там случилось. Благодаря метаинформации (см. выше) он точно будет знать какая версия чего там была установлена. Он будет знать состояние стэка вызовов и т.п. Зачем тут какое-то магическое число?
Если у нас метаинформации нет (скажем у нас не КП а Оберон, а там метаинформации ровно столько же сколько в С++ скажем), то тогда да, ASSERT должен быть поумнее. Но в этом случае опять таки не нужно число. Нужно банально печатать (если у нас нет данных о стэке вызовов): файл, строку, содержимое строки этого самого ASSERT'a (это будет нечто вроде ASSERT(a#b) ). На этапе исполнения накладных расходов тут будет ровно нуль.
-
Нет, я что-то не совсем понимаю зачем это самое целочисленное значение ассерту скармливать.
Я тут полазил по сообщениям о языках, вот что я нарыл:
оригинальный оберон от Вирта: ASSERT отсутствует, есть HALT
оберон-07: ASSERT есть в двух перегруженных видах - с и без числа.
ББ: ASSERT тоже двух видов, HALT присутствует. Разница между ASSERT(FALSE, n) и HALT(n) не поясняется. HALT очень смахивает на лишнюю сущность ;)
Сделаю предположение, что ASSERT с вторым параметром Вирт оставил для случая, когда компилятор делается настолько простым, что не в состоянии вкомпилить номер строки и имя модуля. О нормальном стэктрэйсе в таком случае тоже говорить не приходится. А отлаживаться как-то надо.
P.S. На форуме мало истинных оберонщиков. Они бы сразу ткнули в ASSERT без второго параметра.
-
Первое, что вы захотите от пользователя в случае какой-либо ошибки - это версия.
Да, Вы правы. Версия программы в таких случаях по любому важна.
в документации на КП/BB вроде определены стандартные коды, ... . Этими спецификациями я не пользуюсь.
Что лишний раз показывает бессмысленность подобного рода спецификаций...
Наблюдения показывают, что всё, что носит рекомендательный характер, на практике частенько нарушается. Об этом даже сам Н. Вирт говорил, когда рассказывал про "лазейки" в языке. Наличие этих спецификаций может быть оправдано только тем, что разработчики хотели, чтобы коды ошибок были унифицированы. Возможно, это полезно для коллектива разработчиков. Но я пишу один, и для меня это не важно.
-
Если ASSERT сработал на машине пользователя, то среда должна сформировать слепок состояния программы, дамп памяти, в виде пригодном для последующего анализа.
Стоп. А где в стандарте языка сказано, что среда должна всё это сделать? ;)
-
Разница между ASSERT(FALSE, n) и HALT(n) не поясняется. HALT очень смахивает на лишнюю сущность ;)
Не помню, как предписано стандартом языка, но по факту в BB ассерты проверяются не только в run-time, но даже уже на этапе компиляции. Поэтому ASSERT(FALSE) воспринимается компилятором как семантическая ошибка. Когда я это обнаружил, то был немного удивлён. Для безусловного останова вместо такого ассерта предлагается использовать HALT. В этом случае ошибки не возникает, и компиляция пройдёт успешно.
P.S. На форуме мало истинных оберонщиков. Они бы сразу ткнули в ASSERT без второго параметра.
А, так Вы не знали, что ASSERT можно использовать без второго параметра? :o
-
Нет, я что-то не совсем понимаю зачем это самое целочисленное значение ассерту скармливать. Вот смотрите: сработал ASSERT, отлично. Благодаря наличию метаинформации мы точно знаем CallStack с названиями функции, мы знаем версии всех модулей, знаем структуру функции где оно сработало. В конце концов ничто не мешает также знать и вид логического условия сработавшего ассерта. Всё это мы знаем без наличия исходников.
Если ASSERT сработал на машине пользователя, то среда должна сформировать слепок состояния программы, дамп памяти, в виде пригодном для последующего анализа. Например в виде составного документа. Этот слепок отправляется к разработчику, где он уже спокойно разбирает что там случилось. Благодаря метаинформации (см. выше) он точно будет знать какая версия чего там была установлена. Он будет знать состояние стэка вызовов и т.п. Зачем тут какое-то магическое число?
Если у нас метаинформации нет (скажем у нас не КП а Оберон, а там метаинформации ровно столько же сколько в С++ скажем), то тогда да, ASSERT должен быть поумнее. Но в этом случае опять таки не нужно число. Нужно банально печатать (если у нас нет данных о стэке вызовов): файл, строку, содержимое строки этого самого ASSERT'a (это будет нечто вроде ASSERT(a#b) ). На этапе исполнения накладных расходов тут будет ровно нуль.
Ну вот смотрите, предположим у вас кусок сложных вычислений. Утверждений ASSERT(x >y) рядом штук 10. От все вышеперечисленно будет мало толку. Нужна строка с объяснением логики. Вполне возможно, что в терминах более высокого уровня, чем x и y.
-
Если ASSERT сработал на машине пользователя, то среда должна сформировать слепок состояния программы, дамп памяти, в виде пригодном для последующего анализа.
Стоп. А где в стандарте языка сказано, что среда должна всё это сделать? ;)
Вообще в стандарте, который репорт, мало чего сказано (а то в 16 страниц было бы не уложиться). Много чего отдано на откуп здравому смыслу. По факту, найти сейчас современную реализацию ЯП, которая не позволяла бы диагностировать фатальные проблемы в виде стэка/дампа - очень сложно. Для экстремальных случаев, типа выдать рабочий компилятор/рантайм для экзотической железки за человеко-месяц - да, можно сэкономить и использовать второй параметр в ассерте.
-
Не помню, как предписано стандартом языка, но по факту в BB ассерты проверяются не только в run-time, но даже уже на этапе компиляции. Поэтому ASSERT(FALSE) воспринимается компилятором как семантическая ошибка. Когда я это обнаружил, то был немного удивлён. Для безусловного останова вместо такого ассерта предлагается использовать HALT. В этом случае ошибки не возникает, и компиляция пройдёт успешно.
Да, интересно, зачем на практике такое свойство можно использовать? И как далеко компилятор идет в своем рвении? Любое выражение с константами, дающее FALSE? Или жестко FALSE как лексема?
А, так Вы не знали, что ASSERT можно использовать без второго параметра? :o
Да, не знал, в ББ'шных исходниках второй параметр всегда присутствует.
-
Ну вот смотрите, предположим у вас кусок сложных вычислений. Утверждений ASSERT(x >y) рядом штук 10. От все вышеперечисленно будет мало толку. Нужна строка с объяснением логики. Вполне возможно, что в терминах более высокого уровня, чем x и y.
У нас, кстати, есть неотключаемая версия ассерта с вторым параметром в виде строки. И у меня постоянно возникают проблемы с придумыванием этой самой строки. Приходится вбивать что-то на отвяжись. Все равно будет непонятно, пока не полезешь в код и не посмотришь. А чтобы полезть и посмотреть достаточно имени исходника и номера строки. А еще лучше - полноценный дамп стэка.
P.S. Да, если таки у сложного ассерта есть простое объяснение, то оно просто записывается в виде комментария напротив этого ассерта.
-
У нас, кстати, есть неотключаемая версия ассерта с вторым параметром в виде строки. И у меня постоянно возникают проблемы с придумыванием этой самой строки. Приходится вбивать что-то на отвяжись.
А теперь представьте себе, что вы вбиваете не строку, а число, отдельно в строковых ресурсах прописываете, какая строка ему соответствует, причем на нескольких языках :)
-
Да, при этом неплохо бы еще представить, что enum'ов у тебя также нет :-) Это сулит много радости в не маленьких проектах.
-
... Поэтому ASSERT(FALSE) воспринимается компилятором как семантическая ошибка.
Да, интересно, зачем на практике такое свойство можно использовать? И как далеко компилятор идет в своем рвении? Любое выражение с константами, дающее FALSE? Или жестко FALSE как лексема?
Любое константное выражение, дающее FALSE. Вообще-то я не проверял, но на 100% уверен что так, ибо все известные мне компиляторы производят свёртку констант. А неконстантное выражение на этапе компиляции в общем случае вычислить невозможно, для этого нужно выполнить программу.
По поводу использользования на практике - не знаю. При такой семантике оператор ASSERT(FALSE) лишён смысла.
-
Пример использования ASSERT(FALSE):
- (NSEnumerator *)objectEnumerator
{
NSAssert(NO, @"Must implement a complete subclass of MyMatrix!");
return nil;
}
(это Objective C)