[demidrol 0]

Как известно, tcl-шелл Synopsys DC имеет свое мнение по поводу обработок ошибок. А именно: произошла или нет ошибка в результате исполнения команды можно понять, проанализировав то, что эта самая команда выдала (0 -- ошибка, 1 -- успех).

Обработку такого рода ошибок писать очень накладно (это считай каждую команду надо во что-то оборачивать, типа такого

proc try {cmd} {
    set r [uplevel $cmd]
    if { $r != 1 } {
        error "Error in $cmd"
    }
}

и вызывать уже команды так: try {connect_net netname portname})

А вот нельзя ли как-то указать интерпретатору, что надо останавливать выполнение при первой возникшей ошибке? Иными словами, чтобы команды синопсиса не выделывались, а использовали стандартные тиклевские исключения (error -- catch).

[Avex 1]

foreach id [get_message_ids -type Error] {
	set_message_info -stop_on -id $id
}

Это из мануала dc

 

А так, мне тоже было бы интересно сделать обработчик ошибок, но ничего лучше парсера лога я пока не придумал.

[demidrol 0]

о, спасибо! Действительно, видел же, но напрочь забыл.

[Nick_K 0]

Мы делаем с помощью команды catch, не уверен в поддержке оной в Синопсисе, на Кейденсе работает нормально.

Головной скрипт задаёт конфигурацию и вызывает основной скрипт выполнения команд

...
  if { [catch { sourse main_script.tcl } error_code error_detail ] } {
  	puts "Error occure"
    foreach error_detail $ed {
      puts $ed
    }
  	exit 1
  } else {
  	puts "File sourced OK"
    exit 0
  }

А сама команда catch ловит любые Error'ы и прекращает работу основного скрипта. Экситы поставлены, чтобы сразу вывалится из оболочки, но можно убрать и продолжить работать в консоли.

З.Ы. Такое поведение не покрывает специфические внутренние ошибки. Например у меня в инструменте Modus напрочь отсутствовало прекращение и скрипты выполнялись до конца с кучей эрроров.

[demidrol 0]

нет, для synopsys не подойдет. Их команды по умолчанию не бросают исключения в случае ошибок, а просто выдают 0.

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

[Avex 1]

Мне бы хотелось не просто получать код 1 или 0 от операции, но еще и парсить вывод на предмет слов Error, Warning и т.д. Это не то же самое, что играть с Severity level, поскольку severity не всегда можно менять, и потому что хочется большей гибкости - ставить триггер на определенные слова или фразы в выводе. Пока ничего лучше не придумал, чем редиректить вывод в файл и его уже парсить. При этом замечено, что редирект у кэденса иногда работает криво - часть вывода некоторых команд может не редиректиться (пример привести не могу, нет доступа к тулам. я - безработный :-) ). В идеале -сделать систему сбора и обработки всех ошибок и сообщений. Эдакий QA.

[demidrol 0]

@Alex, в этом смысле у Xilinx ISE прикольно был сделан вывод утилит в режиме интеграции с IDE: оно плевалось XML-м. Очень удобно именно для машинной обработки, сортировки и QA. Увы, вендоры "серьезоного" софта не хотят или не могут осилить такое.

[Nick_K 0]

У вендоров "серьёзного" софта абсолютно иные приоритеты, чем сделать жизнь разработчика легче и нарисовать красивый интерфейс. И им не нужно завлекать людей и делать низкий порог вхождения в отрасль, так как там уже работают тёртые калачи, знающие очень многое. Для всех остальных случаев есть саппорт (если конечно у Вас официальная версия софта). Как говорит мой начальник: "Напиши тикет, там в саппорте сидят люди и им нечем заняться, они страдают от скуки, помоги им делать свою работу" 

[topor_topor 0]

Зачем так заморачиваться? 

У меня все и всегда тулзи сами по умолчанию останавливаются и печатаеют Warning/Error в логе... Дальше баг фиксится и можно продолжать скрипт. 

Да есть опция, включив которую тулза попитается игнорировать Error и пойдет дальше, но смисл имеет если рантайм скрипта больше чем полдня. Чтоби словить побольше багов за один раз и пофиксить.