Когда выбрать проверенные и неконтролируемые исключения

Это максимальная разница между двумя элементами в массиве, и это мое решение:

O (N) временная сложность O (1) сложность пространства

    int[] arr   =   {5, 4, 6 ,7 ,6 ,3 ,2, 5};

    int start   =   0;
    int end     =   0;
    int max     =   0;
    for(int i=1; i<arr.length; i++){
        int currMax =   arr[i] - arr[i-1];
        if(currMax>0){
            if((arr[i] -arr[start])>=currMax && ((arr[i] -arr[start])>=(arr[end] -arr[start]))){

                 end    =   i;
            }
            else if(currMax>(arr[i] -arr[start]) && currMax >(arr[end] - arr[start])){
                start   =   i-1;
                end =   i;
            }
        }
    }
    max =   arr[end] - arr[start];
    System.out.println("max: "+max+" start: "+start+" end: "+end);
197
задан Josh Lee 8 October 2010 в 06:43
поделиться

8 ответов

Правило, которое я использую: никогда не используйте неконтролируемые исключения! (или когда Вы не видите пути вокруг этого)

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

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

-12
ответ дан 23 November 2019 в 05:13
поделиться

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

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

Это - философия, используемая многими платформами. Spring и в спящем режиме, в особенно, приходит на ум - они преобразовывают известную контролируемую исключительную ситуацию в исключение непроверенное точно, потому что контролируемые исключительные ситуации злоупотребляются в Java. Одним примером, о котором я могу думать, является JSONException с json.org, который является контролируемой исключительной ситуацией и является главным образом раздражающим - это должно быть неконтролируемо, но разработчик просто не продумал его.

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

19
ответ дан Yoni 23 November 2019 в 05:13
поделиться

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

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

1
ответ дан David Crow 23 November 2019 в 05:13
поделиться

Вот мое 'заключительное эмпирическое правило'.
я использую:

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

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

<час>

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

Так, например, цель этой конкретной функции ниже состоит в том, чтобы сделать (или добраться, если уже существуют), объект,
значение:

  • контейнер объекта делать/получать ДОЛЖЕН существовать (ответственность ВЫЗЫВАЮЩЕЙ СТОРОНЫ
    => неконтролируемое исключение И очистить комментарий Javadoc для этой вызванной функции)
  • , другие параметры не могут быть пустые
    (выбор кодера поместить это на ВЫЗЫВАЮЩУЮ СТОРОНУ: кодер не проверит на пустой параметр, но кодер ДЕЙСТВИТЕЛЬНО ДОКУМЕНТИРУЕТ IT)
  • CAN результата НЕ БЫТЬ ПУСТОЙ
    (ответственность и выбор кода вызываемого, выбор, который будет очень интересен для вызывающей стороны
    => контролируемая исключительная ситуация, потому что каждый вызывающие стороны ДОЛЖНЫ принять решение, если объект не может быть создан/найден, и то решение должно быть осуществлено во время компиляции: они не могут использовать эту функцию, не имея необходимость иметь дело с этой возможностью, означать с этим проверило исключение).

Пример:

<час>
/**
 * Build a folder. <br />
 * Folder located under a Parent Folder (either RootFolder or an existing Folder)
 * @param aFolderName name of folder
 * @param aPVob project vob containing folder (MUST NOT BE NULL)
 * @param aParent parent folder containing folder 
 *        (MUST NOT BE NULL, MUST BE IN THE SAME PVOB than aPvob)
 * @param aComment comment for folder (MUST NOT BE NULL)
 * @return a new folder or an existing one
 * @throws CCException if any problems occurs during folder creation
 * @throws AssertionFailedException if aParent is not in the same PVob
 * @throws NullPointerException if aPVob or aParent or aComment is null
 */
static public Folder makeOrGetFolder(final String aFoldername, final Folder aParent,
    final IPVob aPVob, final Comment aComment) throws CCException {
    Folder aFolderRes = null;
    if (aPVob.equals(aParent.getPVob() == false) { 
       // UNCHECKED EXCEPTION because the caller failed to live up
       // to the documented entry criteria for this function
       Assert.isLegal(false, "parent Folder must be in the same PVob than " + aPVob); }

    final String ctcmd = "mkfolder " + aComment.getCommentOption() + 
        " -in " + getPNameFromRepoObject(aParent) + " " + aPVob.getFullName(aFolderName);

    final Status st = getCleartool().executeCmd(ctcmd);

    if (st.status || StringUtils.strictContains(st.message,"already exists.")) {
        aFolderRes = Folder.getFolder(aFolderName, aPVob);
    }
    else {
        // CHECKED EXCEPTION because the callee failed to respect his contract
        throw new CCException.Error("Unable to make/get folder '" + aFolderName + "'");
    }
    return aFolderRes;
}
19
ответ дан Community 23 November 2019 в 05:13
поделиться

Вы корректны.

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

, Например:

/**
 * @params operation - The operation to execute.
 * @throws IllegalArgumentException if the operation is "exit"
 */
 public final void execute( String operation ) {
     if( "exit".equals(operation)){
          throw new IllegalArgumentException("I told you not to...");
     }
     this.operation = operation; 
     .....  
 }
 private void secretCode(){
      // we perform the operation.
      // at this point the opreation was validated already.
      // so we don't worry that operation is "exit"
      .....  
 }

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

 IllegalArgumentException: I told you not to use "exit" 
 at some.package.AClass.execute(Aclass.java:5)
 at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
 ar ......

И Вы будете знать то, что произошло. OtherClass в "delegateTheWork" методе (в строке 4569) названный Вашим классом со значением "выхода", даже когда это не было должно и т.д.

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

, То же самое происходит с NullPointerExceptions. Если у Вас есть 700 классов строк приблизительно с 15 методами, которые используют 30 атрибутов, и ни один из них не может быть пустым, вместо того, чтобы проверить в каждом из тех методов для nullability, Вы могли сделать все те атрибуты только для чтения и проверить их в методе конструктора или методе фабрики.

 public static MyClass createInstane( Object data1, Object data2 /* etc */ ){ 
      if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }

  }


  // the rest of the methods don't validate data1 anymore.
  public void method1(){ // don't worry, nothing is null 
      ....
  }
  public void method2(){ // don't worry, nothing is null 
      ....
  }
  public void method3(){ // don't worry, nothing is null 
      ....
  }

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

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

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

при злоупотреблении неконтролируемого исключения что-то подобное произойдет. Пользователи того кода не знают, может ли что-то пойти не так, как надо большая попытка {...} Выгода (Throwable t) появится.

29
ответ дан OscarRyz 23 November 2019 в 05:13
поделиться

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

С контролируемыми исключительными ситуациями Ваша обработка ошибок stategy микроорганизована и ее невыносимое в любой большой системе.

Большую часть времени Вы не знаете, является ли ошибка "восстанавливаемой", потому что Вы не знаете, в каком слое расположена вызывающая сторона Вашего API.

Скажем, что я создаю StringToInt API, который преобразовывает строковое представление целого числа к Интервалу, я должен бросить контролируемую исключительную ситуацию, если API называют со строкой "нечто"? Действительно ли это восстанавливаемо? Я не знаю, потому что в его слое вызывающая сторона моего StringToInt API, возможно, уже проверила вход, и если это исключение выдается, это - или ошибка или повреждение данных, и это не восстанавливаемо для этого слоя.

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

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

43
ответ дан Stephane 23 November 2019 в 05:13
поделиться

От Ученик Java А :

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

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

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

58
ответ дан Espo 23 November 2019 в 05:13
поделиться

правило, которое я использую: никогда не используйте неконтролируемые исключения! (или когда Вы не видите пути вокруг этого)

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

47
ответ дан Konrad Rudolph 23 November 2019 в 05:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: