Руслан Лопатин

строка
promise.then(onFullfiled).catch(onRejected);
на самом деле работает как
promise.then(onFullfiled, err => {throw err;}).then(v => v, onRejected);

Если имеем дело с зарезолвленным/зареджекченным промисом, то здесь первый then ставит микротаск в очередь сразу, а второй - только по выполнении микротаска от первого.

соответственно, для примера

const promises = [
  Promise.reject('rejected1'),
  Promise.reject('rejected2'),
  Promise.resolve('resolved'),
];

микротаски составили такую очередь:

1) err => {throw err;}
2) err => {throw err;}
3) onFullfiled
4) onRejected,
5) onRejected
6) v => v,

Где пункты 1-3 добавились на цикле, а 4-6 по мере выполнения первых трёх.

вот так и вышло, что onFullfiled вылез вперед.

Обратиться на сайт фриланса. Там дадут оценку.

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

А я кажется и сам понял что throw Error - равносильно вызову reject и это уже идет через очередь промисов

Значит executor обернут в try-catch внутри реализации Promise.
И значит всетаки executor - выполняется в обычном call stack
Просто ошибка внутри обрабабтывается

В общем ответ такой:
JPA - это не просто какая-то абстрактная спецификация, там есть вполне конкретные классы, выполняющие конкретные действия. В частности:

import javax.persistence.Persistence;
EntityManagerFactory factory = Persistence.createEntityManagerFactory("dvdPU");

В классе Persistence метод createEntityManagerFactory выполняет вполне конкретные действия (можно посмотреть исходники тут https://github.com/javaee/jpa-spec/blob/master/jav...), а именно:
1. Сначала находит в classpath все возможные классы, которые могут создать EntityManagerFactory.
2. Потом перебирает все, которые нашел, по очереди, каждый раз передавая очередному "создателю" конфиг из persistence.xml.
3. Как только "создатель" создает фабрику, цикл прекращается и фабрика возвращается в нашу программу.

Если мы не указываем в persistence.xml через тег provider конкретного провайдера, тогда фабрику нам создаст первый попавшийся провайдер. Если же указываем, тогда фабрику нам создаст именно тот, который мы хотим. Пусть Persistence нашел в classpath два провайдера в таком порядке: EclipseLink и Hibernate. Он сперва просит EclipseLink создать фабрику и передает ему конфиг. EclipseLink видит, что в конфиге написано "Hibernate" и отвечает: "Извини, братишка, не в этот раз, в конфиге написано, что это хибер должен делать. Так что я не буду". Тогда Persistence идет дальше по списку, просит хибер и передает ему конфиг. Хибер видит, что в provider стоит org.hibernate.jpa.HibernatePersistenceProvider и создает фабрику.

Вот так у нас и оказывается КОНКРЕТНАЯ, хиберовская, реализация фабрики, из которой мы уже дальше получаем такие же конкретные, хиберовские, реализации EntityManager и прочее.

Ну а в classpath все эти провайдеры попадают за счет того, что у нас в pom есть зависимости.

Расскажу из личного опыта:
Мне всегда хочется, чтобы модель, которая используется в БД, и модель, которая используется в контроллере, были одной и той же моделью.
Все просто же: пришёл запрос в контроллер - сохрани в бд; нужно что-то из бд - сделай селект и отправь в контроллер.
Но никогда, ни разу это не было хорошей идеей.

Начнём с того, что как только появляется хоть какая-то вложенность объектов, никто в здравом уме не будет в контроллере передавать эти объекты, ограничиваясь ссылками на них, в лучшем случае (используя их id); закончим вопросами безопасности и консистентности данных, которые сразу, мимо валидации и какого-то сервиса отправляются в бд.

Отвечаю на ваш вопрос:
1. Всегда используйте сервис. Умение сохранять объекты в бд у контроллера противоречит принципу solid
2. Используйте луковую архитектуру. Доменная модель не должна ничего знать о внешних интеграциях.

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

лол
40 лет, а мыслит как 18-и летний юноша-максималист
выучит он "слишком много всего"
ты выучи сначала
потом приходи сюда
когда ты "слишком много всего" выучишь, тебе минимум будет 45 лет

Но вот думаю: А не слишком ли "крутым" я стану?

на первом же собеседовании тебя сотрет в порошок 25-30 летний чувак с опытом и покажет твое истинное место.
это не оскорбления.
это твое будущее.

например
'dev05_dddd'.split( /\d/ ).shift()

Нет никакой нехватки общения. Все гораздо проще. Заказчику элементарно лень писать описание, ему проще созвониться выплеснуть поток своих беспорядочных (часто безполезных) мыслей, а дальше уже вы запонинайте как хотите, понимайте как хотите, вспоминайте как хотите. Я часто отсекаю все ненужные попытки созвониться и требую делать текстовое описание, так как:
1) Это максимально продуманно, заказчик во время написания анализрует то что пишет.
2) В этом легче ориентироваться
3) С этим проще работать, можно дополнять, редактировать