Какие бывают corner cases в программировании?

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

Способны ли вы ещё до написания кода увидеть, где решение сломается, и проговорить это вслух. На лайв-кодинге вопрос часто звучит как «какие тесты вы бы написали к своей функции», и по ответу видно, проверяете ли вы границы по привычке или только по подсказке.

Как отвечать

Сгруппируйте случаи, так ответ звучит системно:

• пустые и крайние размеры: null вместо коллекции, пустой массив, один элемент, одинаковые элементы, очень большой вход, на котором рекурсия упрётся в StackOverflowError;
• целые числа: int переполняется молча, Integer.MAX_VALUE + 1 даёт Integer.MIN_VALUE. Math.abs(Integer.MIN_VALUE) возвращает отрицательное число, а середина отрезка через (lo + hi) / 2 переполняется, правильно lo + (hi - lo) / 2 или (lo + hi) >>> 1. Для строгой арифметики есть Math.addExact;
• дробные числа: 0.1 + 0.2 != 0.3, NaN не равен сам себе, деление на ноль в double даёт Infinity, а в int бросает ArithmeticException. Деньги считают в BigDecimal;
• строки: пустая строка, одни пробелы, символы за пределами BMP (эмодзи занимает минимум два char, и length() не равен числу символов), регистр с учётом локали;
• коллекции: ConcurrentModificationException при удалении внутри for-each, неизменяемый List.of(), сравнение Integer через ==, которое работает только в кэше для значений от -128 до 127;
• время: часовые пояса, переход на летнее время, 29 февраля, конец месяца.

На собеседовании назовите пару случаев до кода, а после напишите по ним проверки. Это ценится больше, чем красивое решение, которое падает на пустом массиве.

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

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

Лечат всё проверкой на null в начале метода, но не решают, что вернуть: пустой результат, Optional или исключение. Контракт метода важнее самой проверки.

Перечисляют общие случаи без связи с задачей. Сильнее назвать три, которые ломают именно ваш алгоритм, чем двадцать из учебника.