Инструмент для выявления проблем в блоках catch

Question

Я ищу инструмент (возможно, время сборки или плагин eclipse), который может помочь мне определить, не я ли я регистрирую трассировку Exception или сообщение.

У нас есть устаревшее приложение, у которого есть блок catch catch, в котором зарегистрировано собственное сообщение об ошибке. Исключение не регистрируется и не выбрасывается. Таким образом, когда возникает проблема, в файлах журналов нет трассировки стека, что помогло бы отладить проблему. Примером этого является:

try { 
do something.... 
    } catch (Throwable exception) { 
    Log.log("<<custom message>>"); 
    } 

Мне нужен инструмент, как Coverity или Checkstyle, которые могут помочь мне определить все такие случаи в моей базе кода.

Спасибо и наилучшие пожелания

Answer 1

Я бы ожидать, чтобы вы могли сделать достойную работу с любым инструментом, который может осуществлять поиск текста с использованием регулярных выражений (например, Grep).

Регулярное выражение будет что-то вроде этого:

 "catch\W*\(.*\)\W*{\W*Log\.log" 

где W обозначает некоторые пробельный распознаватель, который улавливает пробел и символ новой строки.

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

[EDIT] OP указует

Ищу улов блоки, в которых я не делаю следующее - '+' исключения:

try { do something.... } 
     catch (Throwable exception) 
     { Log.log("<<custom message>>" + exception) 

Мы вернулись к регулярному выражению, как довольно приличный взлом. Вам нужна охота на любое место, которое не вызывает Log.log («< < ....>», или если это так, не имеет следующего «+ исключения». Это неудобно кодировать как регулярное выражение без . «не» оператора, но возможно Предполагая оговорка задвижка существует (другое регулярное выражение тест), и существует вызов Log.log, это, вероятно, сделать это:

"catch\W*\(.*\)\W*{\W*Log\.log\(\".*\+^[\+]" 

последняя проверка выглядит, чтобы увидеть, если «+» есть. Все, что соответствует этому, не имеет «+».

В нашей поисковой системе исходного кода (SCSE) используются лексемы языка, а не регулярные выражения, чтобы обеспечить простой поиск, поэтому он имеет немного необычный язык запросов, написанный с точки зрения языковых лексем. Он также позволяет «отрицать» в большем масштабе; вы можете вычесть хиты в двух регионах, и это действительно полезно. Это означает, что следующий запрос будет делать трюк:

'catch' '(' I I ')' '{' I - I=Log '.' I=log '(' S '+' I ')' 

Это находит хиты для всех «поймать» положения и начала блока (если он начинается с «Log», и вычитает прочь любые матчи на лесоповал идиому Цитированные термины - это атомы языка. Я обозначаю «I (dentifier)», это может быть любой идентификатор (просто I) или ограниченный определенным регулярным выражением для идентификатора (из которого «Log» является особенно простым регулярным выражением). для «S (tring)», также позволяя ограничения, которые нам не нужны для этого запроса. Этот запрос имеет два подзапроса, одну часть перед знаком минус, которая находит «catch» и префикс тела catch, и одна часть после знака «минус», который ищет эту идиому, настаивает, что он хочет.Любые совпадения результатов второго подзапроса с первой причиной того, что перекрывающиеся запросы будут «вычтены» (знак минус) из результата. Таким образом, конечным результатом являются «catch clauses, которые не начинаются с этапа ведения журнала».

Для более сложной проверки требуется найти предложения catch и предложения о регистрации, а также проверить, что предложения журнала не встречаются нигде в блоке catch. SCSE не может сделать это сам по себе. Для определения этого могут использоваться более сложные двигатели, которые анализируют и строят АСТ. Я знаю инструменты, которые могут это сделать, и если OP хочет продолжить разработку.