Как удалить отладочные операторы из производственного кода в Java

голоса
14

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

Это легко установить свойство (отладочный = TRUE) и проверить его на каждом отладочном заявление, но это может привести к снижению производительности. Было бы хорошо, если компилятор будет просто сделать отлаживать заявления обращаются в нуль.

Задан 28/08/2008 в 12:40
источник пользователем
На других языках...                            


8 ответов

голоса
23

Две рекомендации.

Во- первых: для реальных лесозаготовок, использовать современный протоколирования пакет как log4j или в Java собственный встроенный в лесозаготовительной. Не беспокойтесь о производительности так, проверка уровня ведения журнала составляет порядка наносекунд. (это целое число , сравнение).

И если у вас есть более чем один оператор журнала, охранник всего блока:

(Log4j, например :)

if (logger.isDebugEnabled()) {

  // perform expensive operations
  // build string to log

  logger.debug("....");
}

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

Во-вторых:

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

 assert (sky.state != FALLING) : "The sky is falling!";

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

Аккуратная вещь, они обрабатывают с помощью специального JVM и могут переключаться во время выполнения вплоть до уровня класса, с помощью параметра VM (без перекомпиляции необходимости). Если не включено, то есть нулевая накладные расходы.

Ответил 28/08/2008 d 13:46
источник пользователем

голоса
10
public abstract class Config
{
    public static final boolean ENABLELOGGING = true;
}

import static Config.*;

public class MyClass
{
    public myMethod()
    {
        System.out.println("Hello, non-logging world");

        if (ENABLELOGGING)
        {
            log("Hello, logging world.");
        }
    }
}

Компилятор удалит блок кода с «Привет, протоколирование мир.» в ней, если ENABLE_LOGGING устанавливается истина, потому что это статическое конечное значение. Если вы используете обфускатор таких как ProGuard, то класс Config будет тоже исчезает.

Обфускатор также позволит такие вещи, как это вместо того, чтобы:

public class MyClass
{
    public myMethod()
    {
        System.out.println("Hello, non-logging world");

        Log.log("Hello, logging world.");
    }
}

import static Config.*;

public abstract class Log
{
    public static void log(String s)
    {
        if (ENABLELOGGING)
        {
            log(s);
        }
    }
}

Метод Log # журнал уменьшил бы ни к чему не в компиляторе, и быть удален обфускатором, наряду с любыми вызовами этого метода и в конце концов даже классом Log сам будет удален.

Ответил 28/08/2008 d 13:22
источник пользователем

голоса
1

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

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

Ответил 28/08/2008 d 15:52
источник пользователем

голоса
0

Этот « трюк » , как сделать ваш отладочный исчезли

public static final boolean DEBUG = false;

if (DEBUG) { //disapeared on compilation }

Пост говорит , что javacдостаточно умен , чтобы проверить static final booleanи исключить отладочные. (Я не лично попробовать)

Для протоколирования, я лично DONOT хотел бы видеть код, как:

if (logger.isDebugEnabled()) {
    logger.debug("....");
}
realImportantWork();

Каротажные вещи отвлекают меня от realImportantWork(). Правильный путь для меня:

logger.debug("....");
realImportantWork()

плюс конфигурация, которая исключает все отладочные сообщения о производстве.

Я имею в виду , что logger.isDebugEnabled()контроль должен быть работа в рамках регистрации, не моя работа. Большинство концепций поддержки среды журналирования , как «регистратор», «LogLevel» .. который может сделать трюк.

Ответил 08/05/2014 d 13:21
источник пользователем

голоса
0

Я хотел бы также настоятельно рекомендую использовать рамки протоколирования.

logger.IsDebugEnabled()Не является обязательным, это просто , что это может быть быстрее , чтобы проверить , находится ли система в уровне отладки перед входом.

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

Вы могли бы протоколирование, как:

logger.error("Something bad happened")
logger.debug("Something bad happend with loads more detail")
Ответил 28/08/2008 d 15:11
источник пользователем

голоса
0

Java содержит какое - то препроцессор самостоятельно. Это называется APT . Он обрабатывает и генерирует код. На данный момент я не знаю , как это должно работать (я не пробовал). Но , кажется, используются для такого рода вещей.

Ответил 28/08/2008 d 13:28
источник пользователем

голоса
0

Использование Java Препроцессор ? (Google Foo низкий , но это ссылка на старых форумах Джоэл обсуждающих его)

Ответил 28/08/2008 d 12:46
источник пользователем

голоса
-2

Чтобы получить ответ на ваш вопрос: я не знаю.

Но вот другое решение вашей проблемы: На мой взгляд, есть два утверждения, которые сталкиваются друг с другом здесь: «отлаживать заявления» и «производственный код».

Какова цель отладки заявления? Помогите избавиться от ошибок в то время как (блок) тестирования. Если часть программного обеспечения должным образом протестирована и работает в соответствии с требованиями, отлаживать заявления не что иное, ИСП.

Я категорически не согласен с оставляя отладочные в рабочем коде. Держу пари, никто не пристает тестирование побочных эффектов отладки коды в рабочем коде. Код, вероятно, делает то, что он должен делать, но это делает больше, чем это? Все ли ваши #defines работать правильно и действительно взять ВСЕ кода отладки вне дома? Кто анализирует 100000 строк предварительно обрабатывается код, чтобы увидеть, если все отлаживать материал ушел?

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

Ответил 28/08/2008 d 13:35
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more