Возвращает ноль после того, как исключение поймано плохой дизайн [закрыто]

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

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

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

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

Обработка ошибок обычно состоит из 3 частей: обнаружение, создание отчетов и восстановление. По моему опыту, ошибки подразделяются на классы серьезности (ниже приведен сокращенный список):

• Журнал только для отладки
• Приостановить все, что происходит, и сообщить пользователю, ожидая ответ продолжить.
• Откажитесь и завершите программу с помощью извиняющегося диалогового окна.

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

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

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

Я думаю, у вас есть два варианта:

1. выбрасывать исключение. Таким образом, клиент должен обрабатывать это каким-то образом (и по этой причине я либо документирую это, и / или проверяю). Недостатком является то, что исключения являются медленными и не должны использоваться для потока управления, поэтому я использую это для исключительных обстоятельств (каламбур)
2. Вы можете использовать шаблон NullObject .

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

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

Если вы не знаете, что вернуть, то это означает, что вы не знаете, как обработать исключение. В этом случае перебросьте его . Пожалуйста, не глотайте это молча . И, пожалуйста, не возвращайте null , вы не хотите, чтобы вызывающий код писал:

Foo foo = bar.getFoo();
if (foo != null) {
    // do something with foo
} 

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

Итак, как я уже сказал, добавьте в метод предложение throws и либо полностью удалите блок try / catch, либо оставьте try / catch, если это имеет смысл (например, если вам нужно иметь дело с несколькими исключениями), и сбросьте исключение как есть или добавьте его в пользовательское исключение.

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

• Как избежать выражений «! = Null» в Java?

Исключения всегда должны быть перехвачены контроллером в конце.
Передача < null > до контроллера не имеет смысла .
Лучше бросить / вернуть оригинальное исключение в стек.

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

Конечно, вы можете использовать

public Object getObject() throws Exception {}

, который может дать родительской функции полезную информацию и предупредит, что может произойти что-то плохое.

По сути, я бы хотел добавить Даффимо с небольшим дополнением:

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

Если вызывающий должен что-то сделать, но затем должен умереть сам, просто сбросьте исключение. Например:

SomeObject doStuff()
  throws PanicAbortException
{
  try
  {
    int x=functionThatMightThrowException();
    ... whatever ...
    return y;
  }
  catch (PanicAbortException panic)
  {
    cleanUpMess();
    throw panic; // <-- rethrow the exception
  }
}

Вы можете также упаковать исключение, например ...

catch (PanicAbortException panic)
{
  throw new MoreGenericException("In function xyz: "+panic.getMessage());
}

Как говорит Джоша Блох в книге « Эффективная Java », null является ключевым словом Java.

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

В вашем примере я бы изменил код следующим образом:

public Object getObject(){
  Object objectReturned=new Object();
  try{
    /**business logic*/
  }
  catch(Exception e){
    //logging and eventual logic leaving the current ojbect (this) in a consistent state
  }
  return objectReturned;
}

Недостатком является создание полного объекта при каждом вызове getObject () (тогда в ситуации, когда объект возвращается не читается и не записывается).

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

Я бы сказал, что это плохая практика. Если получено null, как я узнаю, что нет object или произошла какая-то ошибка?

Я предлагаю

никогда не возвращать NULL, если записанный тип является массивом или коллекцией. Вместо этого верните пустую коллекцию или пустой массив.

Когда тип возвращаемого значения является объектом, вы можете вернуть значение null в зависимости от сценария. Но никогда не глотайте исключение и возвращайте NULL.

Также, если вы возвращаете NULL в любом сценарии, убедитесь, что это задокументировано в методе.

Вот почему так много java-кода раздуто с предложениями if (x!=null) {...}. Не создавайте свои собственные исключения нулевого указателя.

Некоторые мысли о том, как обрабатывать исключения

• Будет ли возвращение null хорошим или плохим дизайном, зависит от исключения и того, где этот фрагмент размещен в вашей системе.

• Если Исключением является NullPointerException, вы, вероятно, применяете блок catch несколько навязчиво (как управление потоком данных).

• Если это что-то вроде IOException, и вы не можете ничего сделать против причины, вы должны выбросить исключение в контроллер.

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