При написании кода, я постоянно проверяю, не возвращает ли obj.GetType() нулевое значение. И это немного напрягает, так как код разрастается быстро. Эта проверка имеет смысл? Может ли этот метод когда-нибудь вернуть null.
Есть ли способо указать, что возвращаемый ссылочный тип не можт быть нулем. Есть же для значимых типом Nullable. А есть ли какой-нибудь NotNullable для ссылочных типов. Хочется чтобы была проверка еще на уровне компиляции, что если возвращаемый тип помечен как NotNullable, то метод не при каких обстоятельствах не должен возвращать null и соответственно комплиятор должен ругаться, если в каких-то случаях возможно возвращение null.
Здравствуйте, Аноним, Вы писали:
А> При написании кода, я постоянно проверяю, не возвращает ли obj.GetType() нулевое значение. И это немного напрягает, так как код разрастается быстро. Эта проверка имеет смысл? Может ли этот метод когда-нибудь вернуть null.
Думаю проверки не требуются Разве могут быть в типобезопасной среде (до MSIL) объекты совсем без типа?
Старайтесь отказываться от GetType() в пользу typeof() где это возможно...
А> Есть ли способо указать, что возвращаемый ссылочный тип не можт быть нулем. Есть же для значимых типом Nullable. А есть ли какой-нибудь NotNullable для ссылочных типов. Хочется чтобы была проверка еще на уровне компиляции, что если возвращаемый тип помечен как NotNullable, то метод не при каких обстоятельствах не должен возвращать null и соответственно комплиятор должен ругаться, если в каких-то случаях возможно возвращение null.
Может со введением в обиход контрактов .NET 4.0 такое будет возможно со статическими проверками...
Nullable<> введён не для этих целей, только чтобы наделить value-type ещё одним состоянием — null, которое они обычно принимать не могут.
Здравствуйте, Пельмешко, Вы писали:
П>Думаю проверки не требуются Разве могут быть в типобезопасной среде (до MSIL) объекты совсем без типа? П>Старайтесь отказываться от GetType() в пользу typeof() где это возможно...
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Пельмешко, Вы писали: П>>Старайтесь отказываться от GetType() в пользу typeof() где это возможно...
L>Как с помощью typeof получить тип объекта?
Никак, это напутствие по дизайну, я написал "где это возможно".
Здравствуйте, Пельмешко, Вы писали:
L>>Как с помощью typeof получить тип объекта?
П>Никак, это напутствие по дизайну, я написал "где это возможно".
А в каких сценариях возможно заменить GetType() на typeof()?
Re[5]: Отлов исключений внутри сборки
От:
Аноним
Дата:
21.03.09 22:29
Оценка:
Здравствуйте, Lloyd, Вы писали: L>Здравствуйте, Пельмешко, Вы писали: L>>>Как с помощью typeof получить тип объекта? П>>Никак, это напутствие по дизайну, я написал "где это возможно". L>А в каких сценариях возможно заменить GetType() на typeof()?
В тех, когда тип известен =) Может у топикстартера там типа:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Lloyd, Вы писали: L>>Здравствуйте, Пельмешко, Вы писали: L>>>>Как с помощью typeof получить тип объекта? П>>>Никак, это напутствие по дизайну, я написал "где это возможно". L>>А в каких сценариях возможно заменить GetType() на typeof()?
А>В тех, когда тип известен =) Может у топикстартера там типа: А>
У "топикстартера" такого кода нету Я стараюсь по максимуму использовать типизированные методы (даже вызываю их рефлекшеном, если тип заранее не известен), в том числе и чтобы использовать typeof(). Но это не всегда получается, и я так думаю, не всегда нужно, поэтому использую GetType(). Я стараюсь писать код по принципу "Если что-то может свалиться, значит лучше поставить дополнительную обработку, чтобы это точно не свалилось". Формально GetType() может вернуть null, поэтому обычно я ставлю проверкуна это дело. Поэтому и посещают меня мысли что было бы неплохо иметь возможность на этапе компиляции контролить это дело. То есть пометил возвращаемое значение как NotNull и забыл про всякие там проверки.
Здравствуйте, Аноним, Вы писали:
А>Я стараюсь писать код по принципу "Если что-то может свалиться, значит лучше поставить дополнительную обработку, чтобы это точно не свалилось". Формально GetType() может вернуть null, поэтому обычно я ставлю проверкуна это дело. Поэтому и посещают меня мысли что было бы неплохо иметь возможность на этапе компиляции контролить это дело. То есть пометил возвращаемое значение как NotNull и забыл про всякие там проверки.
Тут главное не перегибать палку. Проверка на null результата GetType() — это по-моему как раз тот случай, когда проверка излишняя.
А> Я стараюсь писать код по принципу "Если что-то может свалиться, значит лучше поставить дополнительную обработку, чтобы это точно не свалилось". Формально GetType() может вернуть null, поэтому обычно я ставлю проверкуна это дело.
Главное, что б Вы сами морально были готовы, к тому, что GetType() может вернуть null.
Я к тому, что очень интерсно увидеть реальный пример такой проверки: если вдруг null -- что делать? -- ведь реально подкошены основы Мироздания!
Ну и разбирает любопытсво: что за задача решается -- фреймворк какой-нибудь? обилие .GetType() -- несколько, если и не симптоматично, то, во всяком случае, настораживающе, имхо.
Здравствуйте, Аноним, Вы писали:
А> При написании кода, я постоянно проверяю, не возвращает ли obj.GetType() нулевое значение. И это немного напрягает, так как код разрастается быстро. Эта проверка имеет смысл? Может ли этот метод когда-нибудь вернуть null.
В данном конкретном случае проверка не нужна, потому что obj.GetType() не может вернуть null. Об этом довольно ясно написано в MSDN в описании этого метода, да и при наличии базовых знаний устройства .Net это становится очевидно.
Присоединяюсь в прозвучавшему здесь вопросу, а что за код у вас выполняется в случае (obj.GetType() == null). Очень интересно посмотреть
Здравствуйте, ylem, Вы писали:
Y>Я к тому, что очень интерсно увидеть реальный пример такой проверки: если вдруг null -- что делать? -- ведь реально подкошены основы Мироздания!
Если я покажу код в BCL, на шарпе, в котором на null проверяется this, шляпу будешь есть?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Аноним, Вы писали:
А> При написании кода, я постоянно проверяю, не возвращает ли obj.GetType() нулевое значение. И это немного напрягает, так как код разрастается быстро. Эта проверка имеет смысл? Может ли этот метод когда-нибудь вернуть null. А> Есть ли способо указать, что возвращаемый ссылочный тип не можт быть нулем. Есть же для значимых типом Nullable. А есть ли какой-нибудь NotNullable для ссылочных типов. Хочется чтобы была проверка еще на уровне компиляции, что если возвращаемый тип помечен как NotNullable, то метод не при каких обстоятельствах не должен возвращать null и соответственно комплиятор должен ругаться, если в каких-то случаях возможно возвращение null.
По моему господа вопрос не корректен. Вопрос про .Net значит не одна переменная не может быть определена как тип null — НОНСЕНС. Значит функция GetType() всегда вернет значение отличное от NULL. Самый худший вариант — Object.
Y>>Я к тому, что очень интерсно увидеть реальный пример такой проверки: если вдруг null -- что делать? -- ведь реально подкошены основы Мироздания!
_FR>Если я покажу код в BCL, на шарпе, в котором на null проверяется this, шляпу будешь есть?
Вовсе не хотел подвергать сомнению возможность подкашивания Мироздания.
Мне правда интересно, что автор делать-то в таком случае собирается.
Здравствуйте, ylem, Вы писали:
Y>>>Я к тому, что очень интерсно увидеть реальный пример такой проверки: если вдруг null -- что делать? -- ведь реально подкошены основы Мироздания! _FR>>Если я покажу код в BCL, на шарпе, в котором на null проверяется this, шляпу будешь есть?
Y>Вовсе не хотел подвергать сомнению возможность подкашивания Мироздания. Y>Мне правда интересно, что автор делать-то в таком случае собирается.
В MFC, например, делают ASSERT(this != NULL)
А, вообще, NullReferenceException одно из самых нерпиятных исключений (даже, пожалуй, самое неприятное) которое может возникнуть в коде, и желание точно знать, может ли определённый метод вернуть null более чем законно. В С++, например, оператор new может вернуть NULL (кстати, может и в C# тоже, доберусь до студии, проверю). И это надо учитывать. А учитывать можно очень разными способами, — они не так интересны по сравнению с тем, что произошло.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, stump, Вы писали:
S>В данном конкретном случае проверка не нужна, потому что obj.GetType() не может вернуть null. Об этом довольно ясно написано в MSDN в описании этого метода, да и при наличии базовых знаний устройства .Net это становится очевидно.
Как раз, минимальные знания .NET должны говорить о том, что перекрыть GetType() и вернуть там null особой проблемы не представляет — ума для этого много не надо
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Как раз, минимальные знания .NET должны говорить о том, что перекрыть GetType() и вернуть там null особой проблемы не представляет — ума для этого много не надо
Хм, вродеж Object.GetType() не виртуальный. Или имеется в виду скрыть этот метод и заменить новым?
Походу, выражение ((Object)obj).GetType() точно никогда не может быть null при любом непустом obj.
Здравствуйте, _FRED_, Вы писали:
Y>>Вовсе не хотел подвергать сомнению возможность подкашивания Мироздания. Y>>Мне правда интересно, что автор делать-то в таком случае собирается.
_FR>В С++, например, оператор new может вернуть NULL (кстати, может и в C# тоже, доберусь до студии, проверю). И это надо учитывать.
Вот пример, в котором оператор new возвращает null:
#region Using's
using System;
using System.Diagnostics;
using System.Runtime.Remoting.Proxies;
#endregion Using's
internal static class Program
{
private static void Main() {
var instance = new MyClass();
Debug.Assert(instance == null, "instance == null");
}
}
[MyProxy]
internal sealed class MyClass : ContextBoundObject
{
}
internal sealed class MyProxyAttribute : ProxyAttribute
{
#region Overrides
public override MarshalByRefObject CreateInstance(Type type) {
return null;
}
#endregion Overrides
}
А вот простой пример, в котором GetType() возвращает null:
#region Using's
using System;
using System.Diagnostics;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Proxies;
#endregion Using's
internal static class Program
{
private static void Main() {
var instance = GetMyClass();
var type = instance.GetType();
Debug.Assert(type == null, "type == null");
}
private static MyClass GetMyClass() {
var instance = new MyClass();
var proxy = new MyProxy(instance);
return (MyClass)proxy.GetTransparentProxy();
}
}
internal class MyClass : MarshalByRefObject
{
}
internal sealed class MyProxy : RealProxy
{
#region Fields
private readonly MyClass instance;
#endregion Fields
#region Constructor(s)
public MyProxy(MyClass instance)
: base(instance != null ? instance.GetType() : typeof(MyClass)) {
if(instance == null) {
throw new ArgumentNullException("instance");
}//ifthis.instance = instance;
}
#endregion Constructor(s)
#region Properties
private MyClass Instance {
[DebuggerStepThrough]
get { return instance; }
}
#endregion Properties
#region Overrides
public override IMessage Invoke(IMessage msg) {
var call = msg as IMethodCallMessage;
if(call != null) {
Func<Type> func = GetType;
if(call.MethodBase == func.Method) {
return new ReturnMessage(null, null, 0, null, call);
}//if
}//ifreturn RemotingServices.ExecuteMessage(Instance, call);
}
#endregion Overrides
}
Help will always be given at Hogwarts to those who ask for it.