Как обрабатывать ошибки при конвертации строки в число

Что проверяют

Знаете ли вы стандартную идиому ошибок в Go и пакет strconv глубже, чем один вызов Atoi. Следом часто спрашивают, как отличить мусор во входной строке от переполнения и что вернуть клиенту API.

Как отвечать

Базовая идиома: функция возвращает значение и error, ошибку проверяют сразу.

n, err := strconv.ParseInt(s, 10, 64)
if err != nil {
    return 0, fmt.Errorf("parse limit %q: %w", s, err)
}

Что стоит рассказать дальше:

• Atoi и ParseInt: Atoi(s) это ParseInt(s, 10, 0) с приведением к int, а размер int зависит от платформы. Для идентификаторов и сумм явнее ParseInt(s, 10, 64), для беззнаковых есть ParseUint, для дробных ParseFloat;
• тип ошибки: функции возвращают *strconv.NumError с полями Func, Num и Err. Причину проверяют через errors.Is(err, strconv.ErrSyntax) (не число) или errors.Is(err, strconv.ErrRange) (не влезает в тип), сами поля достают через errors.As;
• переполнение: ParseInt возвращает не ноль, а граничное значение типа вместе с ErrRange. Использовать результат без проверки ошибки опасно;
• строгость: пробелы не прощаются, " 42" даст ErrSyntax, поэтому ввод пользователя сначала пропускают через strings.TrimSpace. Знак + допустим, подчёркивания вроде 1_000 принимаются только при base = 0;
• обёртка: %w в fmt.Errorf добавляет контекст и сохраняет цепочку для errors.Is.

В HTTP-обработчике такая ошибка означает кривой ввод, значит ответ 400 Bad Request с понятным текстом, а не 500.

Где спотыкаются

Пишут n, _ := strconv.Atoi(s). На мусоре получается ноль, и дальше код молча работает с выдуманным значением.

Сравнивают ошибки по тексту через err.Error(). Текст не часть контракта, для этого есть errors.Is и errors.As.

Забывают, что ParseFloat принимает "NaN" и "Inf". Если число потом идёт в расчёт суммы или в базу, такие значения надо отсекать отдельно.