Очень спорные утверждения.
У меня вот какие аргументы против:

• На каждом уровне приложения прийдется ловить 100500 видов исключений к которым код не имеет никакого отношения.
• Нарушение "single responsibility principle" и как следствие — трудночитаемый код.
• "Сьеденные" и неправильно обработанные исключения на определенном уровне приложения приводят к гораздо большим потерям времени, чем пройтись по стеку исключения и понять в чем проблема.
• куча болйлерплэйта, который нужно менять, поддерживать, пробрасывать при любом изменении на более низких уровнях.

Как-то странно, приложение расчитано на домашнюю тренировку, но в первом же сете присутствуют турник и бурсья. Хорошо хоть штанга не потребовалась.

без имен, это, конечно, сильно. Все участники собыйтий из этой картинки гуглятся на раз-два :) согласен про "жабу и гадюку", это прям ваш случай.

"Начиная со Spring 3.2" На самом деле ControllerAdvice актуален и в последних версиях спринга, или вы знаете что-то поинтересней?

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

record и публичные поля это не одно и тоже, не вводите людей в заблуждение.

Все логчиные аргументы прокатят.

1. Аргумент рынка — очень хороший как по мне, он показывает, что если человек уйдет, то замена ему будет стоить Х денег. Будте готовы привести доказательства своих слов, если понадобится.
2. Аргумент "вы меня брали как джуна, а теперь я вырос" — не аргумент. Нужно рассказать, что значит вырос. Например — далаю больше задач, задачи выросли в качестве, проработал новые процессы и улучшил определенные KPI. Тоесть, внятно рассказать почему ваша цена как сотрудника выросла относительно начального соостояния.
3. Предложить взять на себя какие-то не эффективные или плохо сделаные вещи. Это тоже аргумент.

В общем, работодатель не всегда видет происходящее глазами работника и наоборот. Если две стороны положат аргументы (аргументы, а не просто слова) на стол, то при адекватности работодателя и работника всегда можно найти решение.

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

Плохие аргумены:

1. "Васе платят больше, а он делает то же, что и я." Вася, возможно, более профессионален, или смог это показать начальству.
2. "Я уже долго тут работаю, а мне не подняли зарплату." Стаж работы не показывает рельный уровень ценности работника.
3. "Вы же видите как я стараюсь, надо повышать зарплату." Старание это хорошо, но нужны результаты
4. "У меня плохой компьютр/монитор/стол — доплачивайте за это." рабочие условия не связанны с зарплатой, их стоит обсуждать отдельно.
5. "Я слышал, что в гугле/яндеске/рогах и копытах платят больше." Слухи — не лучший аргумент. Особенно не проверяемые.

Может это только у меня позитивный опыт, но у меня есть две вещи сказать.

1. Нужно учиться себя "продавать". Если есть сомнения в своих силах, то можно потренироваться заранее на родственние/коллеге/уточке. Этот скил совсем не лишний.
2. Любые переговоры могут зайти в тупик. Это может произойти по вине любой из сторон, и тогда нужно думать о разрыве переговоров (в данном случае, поиске другой работы). Но никогда не нужно априори избегать переговоров.

Что мешает вам приобрести акции своей компании и получить прибыль от её успехов?

Странная позиция. Почему аргументированая просьба о повышении зарплаты/должности выглядит для вас унижением? По мне, это гораздо ближе к переговорам. Может просто не хватает уверенности в себе, или нечего сказать в свою пользу? Тихо обидится и уйти — детсад какой-то. Да и раз в год менять работу тоже так себе перспектива.

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

@Test
public void shouldDeliverMessages() throws Throwable {
  final Waiter waiter = new Waiter();

  messageBus.registerHandler(message -> {
    waiter.assertEquals(message, "foo");
    waiter.resume();
  };

  messageBus.send("foo");
  messageBus.send("foo");
  messageBus.send("foo");

  // Wait for resume() to be called 3 times
  waiter.await(1000, 3);
}

дополнено:

А вот пример из оригинальной статьи, токорый тоже будет работать.

Waiter waiter = new Waiter();
messageBus.registerHandler(message -> {
  waiter.resume();
};
messageBus.publish("one");
messageBus.publish("two");
waiter.await(1, TimeUnit.SECONDS, 2);

Почему в последнем примере waiter будет ждать двух вызовов?

Внедрение зависимостей — это специальный паттерн, который уменьшает связь между Spring компонентами (то есть между различными POJO).

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