исключения, которые никогда не встречаются в Java

#java #exception

#java #исключение

Вопрос:

Я пишу класс для точек и векторов.Я хочу использовать их для вычисления точки и нормы векторов. Это классы point и vector

 public class Point {
    public float x,y;
}
public class MyVector {
       public Point start,end;
}
  

Я пишу этот код для точечного вычисления точки.

 public float dot(MyVector v) throws Exception
{
   if( (start.x != v.start.x) || (start.y != v.start.y))
        throw new Exception("Vectors not begin in same Point");
}
  

Я хочу использовать эту функцию для вычисления нормы вектора.

 public float norm()
{
        return dot(this);
}
  

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

 public float norm()
{
    try
    {
        return dot(this);
    }
    catch(Exception e)
    {

    }
}
  

Но я думаю, что это избыточно. Есть ли способ удалить функцию try и catch в norm?

Комментарии:

1. Вместо этого создайте что-то, что расширяет RuntimeException — вам не требуется пытаться / перехватывать непроверенные исключения. (См. download.oracle.com/javase/tutorial/essential/exceptions /… )

Ответ №1:

Это намерение не может быть выражено в Java. Либо функция dot выдает исключение, либо нет.

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

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

Или вы могли бы реорганизовать его на что-то вроде этого

 public float dot(MyVector v) throws Exception
{
   if( (start.x != v.start.x) || (start.y != v.start.y))
        throw new Exception("Vectors not begin in same Point");

   return unchecked_dot(MyVector v)
}
  

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

 public float norm()
{
    return uncheked_dot(this);
}
  

Ответ №2:

В языке Java нет способа.

Лучший способ справиться с этим — с помощью комментария и повторного ввода.

Например, если вы используете write метод, который принимает Appendable , но передает StringBuilder , то, возможно, вы хотите скрыть тот факт, что Appendable.append выдает IOException , поскольку StringBuilder на самом деле никогда этого не делает.

   try {
    write(myStringBuilder);
  } catch (IOException ex) {
    // Should never happen since StringBuilders do
    // not throw IOexceptions on append.
    throw new AssertionError(ex);
  }
  

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

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

Ответ №3:

Не создавайте простое исключение.

Создайте подкласс RuntimeException и — чтобы упростить перехват восходящего потока — назовите его, например, «DotUndefinedException».

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

Ответ №4:

если у вас есть основания полагать, что dot(…) должен вызывать исключение, возможно, norm(…) тоже должен. Поглощение исключений на самом деле не очень хорошая идея. Но да, если вы действительно хотите, вам нужно написать try catch . Единственным другим вариантом является то, что вы можете вызвать исключение RuntimeException из dot(…), и в этом случае вам не нужно перехватывать.

Комментарии:

1. Не совсем, в этой ситуации dot() выдаст что-то вроде исключения с недопустимым аргументом. Однако это не тот случай в norm(), который не принимает никаких аргументов.