![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
In modern machines, accessing RAM is really slow (compared to anything the CPU does), which means applications that use the caches as much as possible (which is easier when less memory is used) can be up to a hundred times faster than those that don't. And there are many ways in which Java uses more memory than C++.
Тесты, гоняющие цифры, не возбуждают.
Тесты, гоняющие цифры, не возбуждают.
Сейчас доделаю другую задачу и отвечу, please wait...
М, почему оно ещё не забанено, оно же личинка глазова
Утютю ) Говорю что знаю, т.к. писал несколько лет. Получившийся продукт многое говорит о Гослинге, но вам незачем включать мозг. Вы же оцениваете по имени а не по результату.
com.google.common.primitives.Ints.tryParse
А в чем их возвращать? Можно сделать class что-то вроде MutableInteger, но как-то не очень красиво.
Можно возвращать Object[] - но это совсем уж извращение.
Чем так сильно отличает возвращение статуса от кидания исключения?
Можно возвращать Object[] - но это совсем уж извращение.
Чем так сильно отличает возвращение статуса от кидания исключения?
public static int getInteger(String value, int def) {
try {
return Integer.parseInt(value);
} catch (Exception e) {
return def;
}
}
Edited 2013-03-21 09:45 (UTC)
Ты ещё скажи что на NodeJS только упоротые наркоманы пишут!
Чтобы были альтернативные мнения :)
Есть постулат, что строка, не подходящая по формату для преобразования в число - это идеологически не исключение, а вполне штатная ситуация. Потому правильны метод - возвращающий bool результат преобразования, а если все хорошо, то еще и модифицирующий переменную, которую мы ему указали.
да,
(defn parseIntDef
"convert string to int"
[str & [default]]
(try (Integer/parseInt str)
(catch Exception _ default)))
Но наличие таких функций в моей библиотеке меня огорчает :)
(defn parseIntDef
"convert string to int"
[str & [default]]
(try (Integer/parseInt str)
(catch Exception _ default)))
Но наличие таких функций в моей библиотеке меня огорчает :)
Хмм. откуда такой постулат?
В исходном посте в C# - tryParse - попробовать распарсить. в Java - parseInt() - требует распарсить. Вполне логично по-моему.
В исходном посте в C# - tryParse - попробовать распарсить. в Java - parseInt() - требует распарсить. Вполне логично по-моему.
Так мы дойдем, что проверка if() при не выполнении условия тоже будет бросать исключения вместо того, чтобы ветвиться.
С радостью посмотрю на более другие тесты. Линкуйте.
Это можно, но само выполнение подобных действий у меня вызывает ощущение, что я вернулся в 90е годы и занимаюсь изобретением велосипедов :)
Не надо преувеличивать :) Скажем isInteger() исключений бросать не должна.
Опять же, что плохого в исключениях?
Опять же, что плохого в исключениях?
Есть мнение, что исключение - это исключительная ситуация. По определению здесь нет факта исключительной ситуации.
Да ладно. Java вполне может быть быстрой.
Каков критерий исключительной ситуации?
Edited 2013-03-21 10:27 (UTC)
с if часть алгоритмов сильно короче и нагляднее. Ну, еще насчет производительности вопрос сложный.
Ситуация, когда нормальная работа приложения либо модуля не может быть продолжена обычным образом, и вам необходимо вернуться, возможно, на несколько уровней вложенности в первоначальное состояние, передав наверх информацию о ситуации.
Очень простой.
Если работу можно продолжать - исключение кидать не принято.
Исключения - для случаев, когда надо свалится в корень исполняемого потока (main loop или там обработчик выдающий 500 в веб-сервисе).
Делать логику на исключениях - очень нехорошо, но конкретно в данном случае жаба вынуждает это делать.
Если работу можно продолжать - исключение кидать не принято.
Исключения - для случаев, когда надо свалится в корень исполняемого потока (main loop или там обработчик выдающий 500 в веб-сервисе).
Делать логику на исключениях - очень нехорошо, но конкретно в данном случае жаба вынуждает это делать.
Page 2 of 5