Хорошая практика "бросает тишину"

Раньше я читал тонны кода с помощью таких методов, как:

public Object doSomething() throws Throwable {
    ...
}

Это обычная практика?

Каковы плюсы и минусы?

throws Trowable казалось мне, как "агент оранжевый" способ получить Exception- дело сделано

РЕДАКТИРОВАТЬ

  1. Обработка ожидаемых исключений в методе

  2. Бросить неожиданные Исключения (один за другим)

  3. Не волнует ошибок

Это путь?

ОТВЕТЫ

Ответ 1

Вы не должны бросать Throwable. Вот почему.

Throwable - это вершина иерархии вещей, которые могут быть выброшены, и состоит из Exceptions и Errors. Поскольку Errors по определению возникают из неразрешимых условий, бессмысленно включать их в объявление метода. Это оставляет только Exception.

Вместо этого вы должны объявить свой метод с помощью throws Exception.


Обратите внимание, что чем меньше диапазон throws тем лучше.

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

Если ваш метод генерирует исключение, тогда объявите более узкий диапазон, например, throws IOException, MyProcessingException и т.д.

Ответ 2

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

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

  • Независимо от проверенных исключений, вызванных другими вызовами, которые вы делаете в своем методе
  • Независимо от проверенных исключений, которые вы бросаете на цель, исходя из ваших собственных утверждений
  • Какое бы исключенное исключение вы не планировали
  • Ошибки (java.lang.Error), которые являются более глобальными для JVM и среды

Специально излагая исключения, которые вы хотите бросить, вы сообщаете пользователям своего API о том, о чем им следует остерегаться. Например, когда вы используете InputStream, вы заметите, что большинство методов бросают как минимум java.io.IOException, что дает вам полезную информацию о том, что вы должны наблюдать.

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

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

Вот интересная, но интересная статья о злоупотреблении обработкой исключений в целом.

Ответ 3

Функционально это эквивалентно throws Exception, поскольку ошибки не отмечены.

Я не вижу причин объявлять метод броска Throwable. Однако это не означает, что catch и printStackTrace - хорошая альтернатива.

Обычно вы хотите поймать забросы, где вы можете сделать что-то разумное с ними.

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

Ответ 4

Это обычная практика?

В JDK это редко. Это в основном используется, когда неясно, как обрабатывать проверенные исключения.

Каковы плюсы и минусы?

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

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

Разве не лучше поймать и printStackTrace()?

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

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

Ответ 5

Это действительно спорный вопрос. Если метод слишком много исключений приведет к обработке кода обработки ошибок. Несколько раз это не предназначено.

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

Что можно сделать, это классифицировать исключения, такие как BusinessException, ServiceException, так что если у вас есть бизнес - правило, которое гласит, что minimum balance in account can not be less than say 100$, InsufficientBalance BusinessException minimum balance in account can not be less than say 100$, minimum balance in account can not be less than say 100$, minimum balance in account can not be less than say 100$, то InsufficientBalance будет сгенерировано исключение, которое будет ребенок BusinessException

поэтому вы будете похожи на метод

public Object doSomething() throws BusinessException {

 if(!hasMinimumbalance())
  { 
    throw new InsufficientBalance(ErrorCode);
  }
}

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

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

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

Ответ 6

В некоторых редких случаях допустимо бросать Throwable s. Например, @Around советы в Spring AOP обычно объявляются бросать Throwable.

Следующий пример скопирован дословно из документов Spring AOP:

  import org.aspectj.lang.annotation.Aspect;
  import org.aspectj.lang.annotation.Around;
  import org.aspectj.lang.ProceedingJoinPoint;

  @Aspect
  public class AroundExample {

      @Around("com.xyz.myapp.SystemArchitecture.businessService()")
      public Object doBasicProfiling(ProceedingJoinPoint pjp) throws Throwable {
          // start stopwatch
          Object retVal = pjp.proceed();
          // stop stopwatch
          return retVal;
      }

  }

Почему doBasicProfiling объявляет о Throwable? Поскольку исходный метод (то есть точка соединения выполнения) может RuntimeException Error, RuntimeException или исключенное исключение. Поэтому имеет смысл объявить doBasicProfiling бросить Throwable.

Ответ 7

Вы спрашиваете о Throwable специально? Если это так, то это не хорошая практика. Он не предоставляет никакой полезной информации пользователю класса (метода).

Ответ 8

Throwing (и catching) Throwable (или Exception), как правило, является плохой практикой, потому что он "покрывает" любые определенные исключения, которые вы, возможно, захотите поймать. Тогда вам придётся прибегнуть к уродству, как показано ниже:

public void myMethod() throws Throwable {
    if (x) {
        throw new MyException1();
    }
    if (y) {
        throw new MyException2();
    }
}

public void callingMethod() {
    try {
        myMethod();
    }
    catch(Throwable t) {
        if (t instanceof MyException1) {
            // handle exception 1
        }
        else if (t instanceof MyException2) {
            // handle exception 2
        }
        else {
            // handle other exceptions
        }
    }
}

Какая ошибка подвержена ошибкам (и помечена CheckStyle как нарушение кода). Гораздо предпочтительнее иметь такой код:

public void myMethod() throws MyException1, MyException2 {
    if (x) {
        throw new MyException1();
    }
    if (y) {
        throw new MyException2();
    }
}

public void callingMethod() {
    try {
        myMethod();
    }
    catch(MyException1 e) {
        // handle exception 1
    }
    catch(MyException2 e) {
        // handle exception 2
    }
}

Обработка исключения только вызовом printStackTrace() обычно не является хорошей идеей. printStackTrace() отправляет stacktrace в стандартную ошибку, которая может вообще не читаться. Лучшим вариантом является использование средства ведения журнала приложений (например, log4j) для отчета об исключении. Даже тогда, просто регистрировать его может быть недостаточно.

Мое правило:

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

prvate int parseAmount(String amountValue) {
    int amount;
    try {
        amount = Integer.parseInt(amountValue);
    }
    catch(NumberFormatException e) {
        // default amount
        amount = 0;
    }
    return amount;
}

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

private Customer getCustomer(int customerId) throws ServiceException {
    try {
        return customerService.getCustomer(customerId);
    }
    catch(CustomerServiceSpaghettiTangledException e) {
        throw new ServiceException("Error calling the customer service", e);
    }
}

Здесь "ServiceException" - это подкласс Exception, созданный вами. Spring также предлагает для этой цели иерархию исключений.

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

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