Накладные расходы, связанные с Exception и Throwable в Java

Question

Накладные расходы, связанные с Exception и Throwable в Java

Нажмите на меню «Файл», откройте «Структура проекта», затем в разделе «Настройки» должен быть «Проект». Внутри этой вкладки будет параметр SDK Settings, который указывает версию языка, которую вы хотите использовать.

Подробнее см. На странице справки JetBrains («Уровень языка проекта», ). [/ д2]

27

throwable exception java

задан sixtyfootersdude 10 August 2015 в 18:21

5 ответов


         
            
         
            
               
                  
                     java.lang.Exception расширяет java.lang.Throwable, так что это то же самое, что и над головой. Из Javadoc: 


 Класс Throwable - это суперкласс всех ошибок и исключений на языке Java. Только объекты, являющиеся экземплярами этого класса (или одного из его подклассов), бросаются виртуальной машиной Java или могут быть брошены оператором Java throw. Аналогично, только данный класс или один из его подклассов может быть типом аргумента в пункте catch. 
 
  Случаи двух подклассов, Ошибка и Исключение, обычно используются для указания на то, что имели место исключительные ситуации. Обычно эти случаи создаются заново в контексте исключительной ситуации, с тем чтобы включить соответствующую информацию (например, данные трассировки стека). 
                  
                  
                     
                     0

                  
                  
                  
                     ответ дан                      28 November 2019 в 04:11 
                  
                  поделиться
               
                              
                  
                     
      
                                         
                  
               
            
         
         
            
         
            
               
                  
                      Нет, вам нужен свой собственный подкласс, чтобы избежать этого эффекта. 

Exception ex = new Exception() {
    @Override public Throwable fillInStackTrace() {
        return this; // and do nothing else
    }
};


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

                  
                  
                  
                     ответ дан                      28 November 2019 в 04:11 
                  
                  поделиться


                      Вы никогда не должны бросать или ловить .   Объем исключения слишком велики.

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

1

ответ дан 28 November 2019 в 04:11

С компиляцией JIT, на самом деле, не так уж и много подслушивалось, чтобы бросить исключение в Java. Но бросание Throwable не сильно отличается, так как вы получите трассу стека и там.

Если вам интересно, есть очень интересная статья под названием "Эффективная обработка исключений на Java при компиляции just-in-time" (link). Не легкое чтение, но достаточно информативная.

3

ответ дан 28 November 2019 в 04:11

Другие вопросы по тегам:

throwable exception java

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

score 49 · Accepted Answer

Учитывая проблему, поскольку вы выразили ее, у меня есть ощущение, что проблема может не иметь решения. Предположим, что у вас есть две пары элементов {a_1, b_1} и {a_2, b_2} где a_1 в упорядочении a, а b_1> b_2 в порядке B. Теперь предположим, что a_1 = b_1 и a_2 = b_2 в соответствии с оператором равенства A и B. В этом сценарии я Не думайте, что вы можете создать комбинированный список, который удовлетворяет сублистскому требованию заказ.



 Во всяком случае, есть алгоритм, который должен сделать трюк.  (Закодирован в Java-ish ...) 

List<A> alist = ...
List<B> blist = ...
List<Object> mergedList = new SomeList<Object>(alist);
int mergePos = 0;
for (B b : blist) {
    boolean found = false;
    for (int i = mergePos; i < mergedList.size(); i++) {
        if (equals(mergedList.get(i), b)) {
            found = true; break;
        }
    }
    if (!found) {
        mergedList.insertBefore(b, mergePos);
        mergePos++;
    }
}


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

 Алгоритм пренебрегает патологией, которую я упомянул  первый абзац и другие патологии;  например  что элемент B может быть «равным« нескольким элементам »или наоборот.  Чтобы справиться с ними, алгоритм необходимо проверить каждую  b  против всех элементов MergedList, которые не являются экземплярами B., что делает алгоритм  O (N ** 2)  в  лучший случай.  
  -121--3391008-  Друзья  также создает укладку, когда он создан.  Из  Java Docs для  для приготовления : 


 .  


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

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