История изменений

Кутешный QString::toInt() с параметром bool* посмотри, например. Это выходной по сути параметр, при том, что у функции и результат есть, который число возвращает.

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

Невозможность выполнить функцией прямую задачу (в данном случае конверсию в число) точно является исключительной ситуацией, то есть должна триггерить exceptional flow; ошибка это или нет - это вопрос больше логики конкретной программы, чем синтаксиса языка. В данном случае это точно должно быть исключением.

P. S. На самом деле есть один сценарий, где «не всё так однозначно» (С) - warning. Например, QString::toInt() могло бы быть реализовать так, чтобы, например, «64kb» превращалось бы в 64, но дополнительно возвращался бы warning о том, что на самом деле в параметре было не только число; далее вышестоящая логика могла бы принять решение, это ожидаемо или нет. То есть нужно возвращать и результат, и warning - два значения. Типового паттерна я на это не знаю; в Python есть отдельные Warning исключения, но как по мне это неудобно. В своих имплементациях я в функции добавляю параметры вида allow*. Например, в случае QString::toInt() можно было бы передать allowNonStrictConversion, и если он false (то есть с точки зрения логики не ожидается что в параметре не что-то кроме числа), то оно бы бросало exception, а если true, то нет. То есть это ветвление передаётся в функцию. Это делает код более читаемым.

Кутешный QString::toInt() с параметром bool* посмотри, например. Это выходной по сути параметр, при том, что у функции и результат есть, который число возвращает.

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

Невозможность выполнить функцией прямую задачу (в данном случае конверсию в число) точно является исключительной ситуацией, то есть должна триггерить exceptional flow; ошибка это или нет - это вопрос больше логики конкретной программы, чем синтаксиса языка. В данном случае это точно должно быть исключением.

P. S. На самом деле есть один сценарий, где «не всё так однозначно» (С) - warning. Например, QString::toInt() могло бы быть реализовать так, чтобы, например, «64kb» превращалось бы в 64, но дополнительно возвращался бы warning о том, что на самом деле в параметре было не солько число; далее вышестоящая логика могла бы принять решение, это ожидаемо или нет. То есть нужно возвращать и результат, и warning - два значения. Типового паттерна я на это не знаю; в Python есть отдельные Warning исключения, но как по мне это неудобно. В своих имплементациях я в функции добавляю параметры вида allow*. Например, в случае QString::toInt() можно было бы передать allowNonStrictConversion, и если он false (то есть с точки зрения логики не ожидается что в параметре не что-то кроме числа), то оно бы бросало exception, а если true, то нет. То есть это ветвление передаётся в функцию. Это делает код более читаемым.