Россыпь новых скринов Gears of War 2.

Суровые пацаны, жуткие монстры, командный мультиплеер, отличная атмосфера далёкого будущего – все как я люблю.
Ну и, по всей видимости, “XBox only”.

Интересная статья, рассказывающая о соответствии машин из GTA4 реальным.

Dukes:

Dodge Charger 1970:

Перевёл в меру художественных способностей замечательную статью Patrick Cauldewell – Exception handling policy:

Я затрагивал эту тему ранее, но сейчас мне бы хотелось подробнее развить собственную теорию (или описать предпочтения) политики обработки исключительных ситуаций в C#, открывая тем самым широкие возможности для дебатов, однако я бы хотел описать то, во что верю.

Код, приведенный в данной статье, обладает рядом ограничений, и по ходу изложения эти ограничения будут формулироваться и уточняться.

• Имена методов образуются от глаголов. Сейчас я увлечен применением глаголов и существительных в исходных текстах (что, как я недавно узнал, делает меня приверженцем Домен-ориентированного подхода к проектированию)
  • Если метод подразумевает перевод денег с одного банковского счета на другой, то он должен называться Transfer.
  • Если метод не может выполнить обязательства, наложенные на него отглагольным именем, то он должен возбудить исключение. Т.е. если метод Transfer не может перевести деньги он должен возбудить исключение. Точка.
• Перехватывай только те исключения, которые ты знаешь как обработать. Конкретизируй.
  • Не перехватывай System.Exception
    • Если ты не знаешь, какого исключения ждать, значит ты не знаешь как его обработать. Отправь его выше.
    • Перехват System.Exception, суть попытка разрешить настоящую исключительную ситуацию, которую ты не предвидел.
• Реализуй набор исключительных ситуаций специфичный для твоего приложения, не скупись.
  • Разрабатывай исключения настолько точно описывающие ситуацию, насколько это возможно.
    • Если я пишу функцию Transfer, при этом на счете-отправителе недостаточно средств для проведения операции, порождай InsufficientFundsExceprion. Не ArgumentException, ApplicationException или InvalidOperationException.
  • Скрывай исключения описывающие реализацию приложения, оборачивая их в исключения ориентированные на пользователя.
    • Если ты реализуешь конфигурирование системы, и процесс инициализации читает данные из XML-файла настроек, а самого файла при этом не оказалось – не порождай FileNotFoundException. Оберни его в ConfigurationInitializationException.
      • Пользователю наплевать на твои конфигурационные файлы, его волнует ошибка инициализации приложения.
      • При использовании твоего модуля пользователь должен перехватать ConfigurationInitializationException для отслеживания корректности инициализации твоего модуля, а никак не FileNotFoundException.
      • Если ты решил поменять способ инициализации приложения с XML файла на данные из ДБ, не заставляй пользователя знать твою внутреннюю кухню и заботиться о перехвате DbNotFoundException. Он должен по прежнему отслеживать появление ConfigurationInitializationException.
  • Навяжи катосмизованные исключения пользователю
    • В Java ты можешь проверять это во время компиляции
    • В .NET ты можешь добавить описание исключений в XML-документацию снабдив их элементом . Это не сделает их применение обязательным, но так они хотя бы будут задокументированны.
  • Убедись, в верности реализации конструкторов твоих исключений и в возможности их сериализации
    • В VS 2005 существует шаблон для генерации готового класса, реализующего исключение
  • На самом деле может быть очень специфические причины, по которым необходимо перехватывать System.Exception (хот я в это и не верю)
    • Ты никогда не должен перехватывать Exception, порождая взамен что-то другое.
      • Если ты не заботишься о стабильности твоего кода, зачем ты его пишешь? Возможно, это указывает на проблемы проектирования.
    • Если ты застукал себя за тем, что пытаешься найти аргументы, почему необходимо перехватить Exception, скорее всего у тебя проблемы с проектированием.
      • Если существуют реальные причины, по которым твое приложение должно «упасть». Если никто не знает, как обработать такую исключительную ситуацию, должно ли твое приложение продолжать работать? Или стоит оставить все свои проблемы и закрыть приложение?
      • Если твое приложение читает из базы данных, а базы данных нет, должен ли ты продолжать работу и вываливать в лог ошибки или просто закрыть приложение? (Понятно, что это зависит от того насколько долго база данных будет недоступна и .т., но я начал углубляться, суть то вы уяснили, так? )

YMMV, вперед.

Очень правильная статья. Согласен по всем пунктам.

Вот и наступил долгожданный момент.

Требовалось немного терпения – отстоять очередь, и диск с игрой в руках!

В нагрузку к диску для консоли XBox 360 давали “тематический плакат, напечатанный на пластике”, шапку с козырьком и надписью XBox 360 и игру “Crackdown”.

В коробке GTA IV, кроме самого диска, обнаружилась карта Liberty City и Путеводитель.

По мере появления новостей с фронта завоевания Liberty City буду писать.

Спешу поделиться отличной новостью, совсем недавно, силами Степана, открылся ресурс Triominos.ru, посвященный всевозможным настольным играм. Тримтино, ей-ей, Уно и еще тьма всего. Параллельно, по мере возможностей, ширится энциклопедия настольных игр. Но это еще не все. На сайте работает, магазин.
В общем, добро пожаловать!