Чтение и валидация параметров data driven объектов

Предположим, у нас есть класс CLight.

class CLight {
public:
  void CLight ( const DataBlock &block);
protected:
  vec4 color;
  float radius;
}

Блоком данных может быть XML, Lua таблица либо иное другое представление.
Пример:

SuperLight = {
     color = vmath.vec4(1.0, 0.5, 0.5, 0.0); 
     radius = 10.0;
  }

Конструктор принимает блок данных, откуда объект должен считать параметры color и radius.
Выглядеть это может так:

CLight::CLight ( const DataBlock &block ) {
  block.Read( color, "color" );
  block.Read( radius, "radius" );
  if (radius<0) {
    // ...
  }
}

Вопрос: что делать в случае отсутсвующих или неправильных параметров?
Варианты:
1. Кидать исключение, тем самым прекращая создание объекта.
2. Выводить warning в лог и исправлять значение на значение по умолчанию или на граничное правильное.
3. Ни чего не делать: просто тихо исправлять значение.

Discuss!

>1. Кидать исключение, тем самым прекращая создание объекта.
Я бы поступил именно так - что не предполагается разработчиком - ошибка, ошибок быть не должно ни в коем случае. Ежели полагается, что могут передаваться некорректные данные(хотя само словосочетание "некорректные данные" предполагает ошибку, а их как я говорил быть не должно), то выриант
>2. Выводить warning в лог и исправлять значение на значение по умолчанию или на граничное правильное.
еще кое как можно использовать. Хотя warning предполагает, что его исправят - так лучше к исправлению сразу принуждать - использовать вариант 1(ИМХО).
А это
>3. Ни чего не делать: просто тихо исправлять значение.
по моему даже обсуждать не надо - абсурдный вариант...

Paltr
> Я бы поступил именно так - что не предполагается разработчиком - ошибка, ошибок
> быть не должно ни в коем случае. Ежели полагается, что могут передаваться
> некорректные данные(хотя само словосочетание "некорректные данные" предполагает
> ошибку, а их как я говорил быть не должно), то выриант
Ок. У нас есть скрипт с описанием 1000 объектов.
Потом программисты почесали репу и вспомнили, что нужно добавить еще один параметр: в случае CLight -  bool shadow.
При загрузке вывалится 1000 исключений. Как следствие - сидеть и исправлять 1000 объектов?

Demiurg-HG
В таком случае аргумент bool shadow должен позиционироваться как необязательный с default значением. Только так. По другому ИМХО нелогично...

По моему скромному, но авторитетному мнению, дефолтное значение должно быть предусмотрено абсолютно для всех параметров, за исключением определяющих идентичность объекта (идентификатор и, возможно, класс). Варнинги об отсутствии/присутствии излишеств/несоответствии типа/структуры - в лог, но регулировать дебажным свитчом.
Иначе при любых флуктуациях формата будет трудно. Да и обратную совместимость с таким раскладом обеспечить проще.

Я бы добавил в DataBlock::Read параметрами дефолтное значение и флаг "обязательно должно быть" (как вариант - получать флаг из NULL/nil/etc. в дефолтном значении). Нету, но должно быть - ассерт.
imho,  конечно.

Не раз встречал системы со всеми тремя вариантами. Лично мне больше всего симпатизирует второй + замечание keltar, потому что:
1) становится адом, когда полей данных становится слишком много, при этом бОльшая часть из них носит опциональный характер + проблемы с обратной совместимостью
3) ну слишком много делать втихоря - тоже не вариант, хотя такие системы есть и работают вполне счастливо.