Почему String.indexOf не используют исключение, но возвращаются-1 когда подстрока, не найденная?

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

Последнее, что я слышал об этом, было ...

«Вы бросаете исключение, когда ваш метод не может делать то, что он обещает '- Джефф Рихтер CVC 2-е изд

• IndexOf () обещает вам вернуть индекс первого вхождения символа / строки. Он вызвал бы исключение, если бы по какой-то причине не смог выполнить свою работу. Он выполнил свою работу, но не нашел строку и, следовательно, возвращает -1, чтобы передать результат «не найден».
• File.Open () выдаст исключение FileNotException для несуществующего пути к файлу, поскольку он не может сделать то, что он обещает .. т.е. открыть указанный файл.

Намного легче справиться с проверкой на -1, чем с перехватом исключения.

Помимо аргументов против исключений в целом, я бы добавил, что -1 может быть полезным результатом indexOf и lastIndexOf, а не просто специальным значением. Например, для синтаксического анализа имени файла из строки, которая может содержать или не содержать путь:

String filename = arg.substring(arg.lastIndexOf('/') + 1);

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

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

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

Также потому, что исключения дороги с точки зрения производительности

Здесь много хороших ответов. Это проблема дизайна, в которой прагматизм преобладает над следованием «правилам». В этом случае существует несколько конфликтующих «правил»:

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

vs.

• не создавайте исключения во время рутинного выполнения кода, только когда происходит что-то непредвиденное

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

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

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

В псевдосинтаксисе:

class Option[a] = Some[a] | None,

где a - параметр общего типа, Some представляет результат со значением и None non -result без значения.

в индексе. В случае, если у вас будет:

Option[Integer] indexOf(char c) = {
   if(found) return Some(index)
   else return None
}

, и вы используете это следующим образом:

result = "uncle".indexOf('c')
result match {
  Some(i) => System.out.println("index was: " + i);
  None => System.out.println("no value");
}

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