Можно ли бросать исключение из конструктора?
Коротко: Да
Чуть более длинно:
https://isocpp.org/wiki/faq/exceptions#ctors-can-throw

Обычно конструктор вызывает страхи потому что нет уверенности в том как он работает. Вроде как особый метод, который находится на границе когда объект вроде как создан, а вроде как и нет (не инициализирован). Отсюда мысль "мало ли что". В свой практике я каких-то диких проблем с бросанием исключений в конструкторе не встречал.

Кстати, да. Но мне такой терминологией пользоваться неудобно. Я не знаю кто изначально придумал отделять поля (field) от свойства (property), думаю это впервые появилось в С#. Но проблема вот в чем: поле - это техническая реализация свойства, т.е. поле - это "переменная" класса, а свойство - это геттер или сеттер для этого поля. Запутались?

Проблем в том, что эта терминология еще хуже проявляет себя когда вы работаете с заказчиком (вспоминаем про DDD и Ubiquitous Language) у вас есть объекты предметной области, и для их описания вполне достаточно свойств и методов.
Более того, если сказать бизнес аналитику, что кроме свойств в обсуждаемом объекте есть еще и поля, то он просто этого не поймет.

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

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

Есть общее для всех наук определение "свойства" и только в информатике из него умудрились сделать не пойми что.
Тут наверняка и проблемы перевода, и то что информатика отдельно, а программисты отдельно. Нет системного подхода в программировании, все стихийно

TGIF а значит очередной конкурс с розыгрышом подписки уровня "STREAM".
Тема свободная, публикуйте свои авторские фото в этой теме и то фото, которое соберёт больше реакций, определит победителя.
Желательно убликовать что-то свящангое с лайфстайлом программиста.

Признаки того, что у программиста все хорошо с абстрактным мышлением:
1. Умение проектировать "на бумаге", не используя синтаксис ЯП
2. Присутствие интерфейсов и абстрактных классов в коде (dip)
3. Умение построить мат. модель или модель предметной области
4. Умение разбивать задачу на уровни абстракции
5. Понимание архитектурных границ и разделения обязанностей.

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

На soer.pro опубликовал 24ое архитектурное видео (архитектурные стримы) по проектированию RESTful приложений.

Согласны ли вы с утверждением, что принцип инверсии зависимостей (DIP) в JavaScript не применим? Палец вверх - да, остальное нет.
Если считаете, что применим, то в комментах интересно услышать как это должно выглядеть?

Вот еще один вопрос, который показывает понимание DI и IoC. Вопрос звучит так "Всегда ли при использовании (dependency injection) DI осуществляется инверсия управления (IoC)"? Палец вверх - да, остальное - нет.
Объяснение своего понимания можно дать в комментариях.

Я не зря спросил про DI и IoC. Это пример того как первоначально прозрачная и понятная концепция "замусорилась". Появился IoC 1,2,3 типа и DI (что тоже самое).
Хотя по смыслу DI куда ближе к обычному полиморфизму, а не IoC. Но концепция "управления" сложная, поди разберись кто там кем управляет и у кого прямой поток, а у кого инвертированный. Практика, как всегда, не требует таких сложных "измышлений".

Источник: https://web.archive.org/web/20040202120126/http://www.betaversion.org/~stefano/linotype/news/38/

Вопрос из чата, интересно мнение сообщества на этот вопрос.

TGIF, ну что снова пятница и снова розыгрыш подписки STREAM на soer.pro
Напоминаю, что эта подписка дает доступ к более чем 25 часам записей на тему архитектуры софта.
Сегодня у нас тема забавные случаи из жизни Айтишника. Напишите в комментариях какой-то забавный случай который произошел не обязательно с вами, но чтобы было связано с айти.
Пост который наберет больше всего реакций - победил.

Награда "Золотой Соер" наконец-то дошла до ее законного обладателя. Поздравляю еще раз!
https://www.youtube.com/watch?v=VKVE8dnAjtI

Запускаю стрим...
https://youtu.be/MARm6ttnExs

На soer.pro открыл доступ к ответам на вопросы для всех участников. Так что все желающие, совершенно бесплатно, могут заходить на platform.soer.pro в раздел "Вопрос ответ" - "Все вопросы" и слушат записи (там в основном аудио).

Я тут подумываю делать разборы на код своих коллег, сравнивать стиль, искать хорошие практики.
Отсматривая видосы, у Димыч АйТи Камасутра нашел примерчик, где он начинает id нумеровать с нуля.
Это не очень хорошая идея, потому что в JS, ноль - это falsy значение, а все остальные значения truthy.
В целом ID - это не индекс массива, он должен быть положительным числом. А ноль использовать как аналог "незаполненного поля" или null

Очень распространенное заблуждение, что идентифицируются только реальные данные.
Построение математических моделей наглядно показывает эту проблему. По сути убрав "единичный элемент" или "нейтральный элемент" мы увеличиваем количество исключений в нашей системе в разы.
Хороший пример единичного элемента - ноль. Без этого элемента даже базовая школьная математика ломается. Тоже самое происходит в программе, в которой не предусмотрен нейтральный элемент. Попытки сделать "универсальный" нейтральный элемент в виде - null в большинстве случаев не решают проблему исключений. Поэтому и появился паттерн null object.
Рекомендую всегда использовать единичный элемент для любых наборов элементов из предметной области, с уникальной идентификацией этого элемента. Этот технический момент в разы повышает устойчивость и надежность программ, позволяет легко строить математические модели, например, используя моноиды.