Debug.Assert против условной компиляции

Рассмотрим код ниже:

#if DEBUG
    if (Systems.Contains(system))
        throw new InvalidOperationException("System already registered");
#endif

    Debug.Assert(!Systems.Contains(system), "System already registered");

Раньше я делал первое, с тех пор я обнаружил Debug.Assert.

Есть ли причина, по которой мне не следует всегда отдавать предпочтение Debug.Assert?

  1. Он существует только в отладочном коде (имеет атрибут [Conditional("DEBUG")]).
  2. Мне кажется, что это больше подходит для моего намерения (проверки работоспособности кода, а не создание исключений, которые будут обработаны позже).
  3. Это меньше кода для написания.

debugging c# conditional-compilation
person George Duckett    schedule 23.11.2011    source источник
comment
Debug.Assert побеждает каждый раз для меня   -  person David Heffernan    schedule 23.11.2011
comment
если честно, я бы предпочел использовать режим выпуска в 99% случаев, поэтому редко использую либо   -  person jk.    schedule 23.11.2011
comment
@jk.: Верно. В данном случае это для игры, поэтому подобных проверок лучше избегать, если это возможно, но это нормально для более раннего получения ошибки при отладке.   -  person George Duckett    schedule 23.11.2011

Ответы (1)


arrow_upward
4
arrow_downward

Вы всегда можете использовать Debug.Assert(), потому что этот класс также соответствует условному выражению DEBUG:

[Conditional("Debug")]

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

ConditionalAttribute применяется к методам, определенным в классах Debug и Trace.
http://msdn.microsoft.com/en-us/library/system.diagnostics.conditionalattribute.aspx

person CodeZombie    schedule 23.11.2011
comment
+1 Спасибо за информацию, хотя я уже знал о ConditionalAttribute (отредактировано, чтобы было понятно). - person George Duckett; 23.11.2011
comment
Отлично, тогда я бы использовал вашу 3. Это меньше кода для написания. как основная причина Debug.Assert() :-) - person CodeZombie; 23.11.2011
comment
Спасибо, я оставлю это открытым на некоторое время, чтобы посмотреть, есть ли другие ответы (не забыл принять). - person George Duckett; 23.11.2011