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

Question

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

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);
}

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

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

    }
}

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

Answer 1

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

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

Вы можете либо жить в этой ситуации, либо перейти на использование только 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);
}

Answer 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, вы даете сопровождающим кода больше информации о том, что пошло не так.

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

Answer 3

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

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

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

Answer 4

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