2015-02-13 2 views
2

Рассмотрим пример добавления двух шестнадцатеричных чисел, представленных в виде массива символов: например: 2A и 1D.Что необходимо отложить проверку исключения IllegalArgumentException?

Теперь, up up F действительны, но G-Z недопустимы для 16 бит. У меня есть два случая ниже, чтобы бросить IllegalArguments, в случае 1 он брошен в начале, до того, как начнется даже добавление. Во втором примере это происходит, когда выполняется additon.

Пожалуйста, не предлагайте изменения фрагмента кода, его портной, чтобы задать мой вопрос. Возникает вопрос: лучше ли использовать/не применять обычную практику IllegalArgument во время алгоритма m (в данном случае дополнение), а не заранее?

Случай 1:

  1. Если char1.length == 0 или char2.length == 0 бросок illegalargument.
  2. Проверьте каждый символ в char1, если какой-либо символ является незаконным, то бросайте нелегальные карты.
  3. Проверьте каждый символ в char2, если какой-либо символ является незаконным, а затем бросайте нелегальные.

Cons of case 2: Extra for loop to check each char in char arrays. O(n)

Случай 2:

  1. Если char1.length == 0 или char2.length == 0 бросок illegalargument.

for (; j >= 0; j--, i--) { 
      int num1Digit = Character.digit(longNum.charAt(i), radix); 
      if (num1Digit == -1) throw new IllegalArgumentException("Invalid radix for character"); // eg: 1Z, and radix is 16. 
      int num2Digit = Character.digit(shortNum.charAt(j), radix); 
      if (num2Digit == -1) throw new IllegalArgumentException("Invalid radix for character"); // eg: 1Z, and radix is 16. 

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

ответ

3

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

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

Лично я предпочитаю иметь как можно большую часть валидации в начале метода - таким образом, из самого кода становится ясно, что такое ожидания, а «работа» кода может быть собрана вместе , предполагая действительный ввод (как это происходит после проверки).

Иногда, однако, вы знаете только, действительно ли что-то действует, когда вы уже закончили . некоторая работа - это раздражает, когда это происходит, но иногда это неизбежно. Просто попробуйте сделать эту раннюю работу «местной» (без побочных эффектов), если это возможно.

Смежные вопросы