Здравствуйте, Dog, Вы писали:
Dog>Необходимо вернуть результат функции и виде строки. Сабж.
У МС в гайдлайнах написано что вместо строк null-ы лучше не возвращать. Т.е. исходить из того, что такой клиентский код не должен бросать исколючение:
if (someObj.StringValue.Length == 0)
{
...
}
Что кошернее возвращать, null или "" ?
От:
Аноним
Дата:
09.11.04 09:23
Оценка:
Это смотря как удобнее после вызова проверять:
if (ret != null)
или
if (ret != "")
в общем случае null более широкое понятие, чем пустая строка, поэтому это предпочтительнее визуально, код будет одинаково выглядеть для всех проверок значений ссылочных типов, == или != null.
Здравствуйте, Dog, Вы писали:
Dog>Необходимо вернуть результат функции и виде строки. Сабж.
Если необходимо результат вернуть ввиде строки, то просто нужно поставить проверку внутренней логики функции.
И если условие не удослетворяеться по тем или иным причинам, то возвращать string.Empty.
Dog>>Необходимо вернуть результат функции и виде строки. Сабж. ВВ>У МС в гайдлайнах написано что вместо строк null-ы лучше не возвращать. Т.е. исходить из того, что такой клиентский код не должен бросать исколючение: ВВ>if (someObj.StringValue.Length == 0) ВВ>{ ВВ> ... ВВ>}
Нечто подобное было написано в "Java. Эффективное программирование", вроде. Сам я склоняюсь к тому же мнению. Вот только что-то с утра проглючило
Здравствуйте, Banch, Вы писали:
Dog>>Необходимо вернуть результат функции и виде строки. Сабж.
B>вообще лучще кидать исключение, чтоб никаких неоднозначностей не было
Далеко не лучше, ой как не лучше
Здравствуйте, migel, Вы писали:
B>>вообще лучще кидать исключение, чтоб никаких неоднозначностей не было M>Далеко не лучше, ой как не лучше
почему?
конечно бывают случаи когда лучше возвращать -1 или "", но они как раз крайне редкие
Здравствуйте, Banch, Вы писали:
B>вообще лучще кидать исключение, чтоб никаких неоднозначностей не было
Исключения нужно выбрасывать в исключительной ситуации, т.е. когда нарушается нормальный ход выполнения. Если же логикой программы допускается возврат пустой строки, то исключения ни к чему, имхо.
Здравствуйте, Banch, Вы писали:
B>Здравствуйте, migel, Вы писали:
B>>>вообще лучще кидать исключение, чтоб никаких неоднозначностей не было M>>Далеко не лучше, ой как не лучше B>почему? B>конечно бывают случаи когда лучше возвращать -1 или "", но они как раз крайне редкие
Нельзя строить логику обработки данных на исключениях
А вообще по этому поводу уж столько копий сломано, что повторяться не имеет смысла — ибо Гугл рулит
>Я не единыжды читал, что не стоит этого делать, но толковых доводов почему этого не стоит делать, так и не услышал.
Если в любом случае будет возвращаться string, пусть и пустой, у возвращаемого значения всегда можно без приключений (NullReferenceException) и лишних проверок вызывать методы string'a.
Здравствуйте, Dog, Вы писали:
Dog>Необходимо вернуть результат функции и виде строки. Сабж.
Паттерн "Special Case" (из Фаулера "Архитектура корпоративных приложений"). Введите особый объект, отвечающий за особую ситуацию: в частном случае пустая строка, но лучше ввести какую-либо константу (и с ней потом сравнивать), потому что пустая строка в процессе разработки может стать валидным объектом, имеющим самостоятельное значение.
Re: Что кошернее возвращать, null или "" ?
От:
Аноним
Дата:
11.11.04 05:10
Оценка:
Я так понял, что раз у автора выбор между null и "" значит функция возвращает что-то пустое только в случае неудачи, то есть вызывающий код должен вопринять подобный возврат как своеобразный код ошибки. Бросать Exception — некорректно, так как исключением это является для вызывающего а не для вызываемого кода.
Если взглянуть на стандартную библиотеку — там о неудаче принято сообщать при помощи null, а не пустых строк или Special Case, так как null это однозначно, а "" может иметь большее значение.
Так что если "" или null это сигнал о проблеме (типа что-то не найдено) лучше вернуть null.
Special Case хорошо, но тогда и вызывающий код и вызываемый должны иметь общее знание о некоей константе, то есть код будет более связанным.
Special Case хорош тогда, когда валидный экземпляр объекта должен быть возвращен В ЛЮБОМ САМОМ РАСПЛОХОМ СЛУЧАЕ, или когда используются какие-то метки или теги, определяющие логику обработки, так что я за null.
Насчет somestring.Length==0 vs somstring=="" это все понятно, что первое лучше, но это не значит, что something!=null чем-то хуже. Тем более что под проверку на Null заточен синтаксис Debug,Trace,NUnit и т.д.
То есть:
string res = myFunk();
Assert.IsNotNull(res); //ИМХО понятный и почти что в декларативном стиле код
if(res.Length==0)
{
firstLogic();
}
else
{
secondLodgik();
}
или даже
string res;
Assert.IsNotNull(res=myFunk());
ИМХО Null на то и Null, при этом это не БД, издержек на доступ и сверку с Null нет...
Здравствуйте, migel, Вы писали:
B>>>>вообще лучще кидать исключение, чтоб никаких неоднозначностей не было M>>>Далеко не лучше, ой как не лучше M>Нельзя строить логику обработки данных на исключениях
Вот я пишу класс для коннекта с сервером. Метод Login, например, у меня как раз бросает исключение. (я, правда, думаю, стоит ли писать свои классы исключений или оставить Exception). Не через код возврата же работать...
Так реализованы функции типа Connect в FCL.
Здравствуйте, StanislavB, Вы писали:
SB>я, правда, думаю, стоит ли писать свои классы исключений или оставить Exception
есть хороший способ бросать только одно свое исключение, а в нем сделать свойство по которому различать что именно произошло
плюсы:
избавляет от постоянно написания классов эксепшнов под каждый чих
удобно для логирования и анализа эксепшнов, потому как понятно где лежат тип и дополнительные параметры
минусы:
нельзя четко ловить нужное исключение
но можно написать несколько методов для фильтрации
например:
catch( Exception e )
{
MyExc.CheckMyExc( e, "MyTypeZZZ" ); //прокидывает эксепшн дальше, если это не MyExc
// тут обработка того, если это действительно MyExc с типом "MyTypeZZZ"
}
получается почти как на VB, где есть
catch ... with
Re: Что кошернее возвращать, null или "" ?
Hello, Banch!
SB>> я, правда, думаю, стоит ли писать свои классы исключений или оставить SB>> Exception
B> есть хороший способ бросать только одно свое исключение, а в нем сделать B> свойство по которому различать что именно произошло плюсы: B> избавляет от постоянно написания классов эксепшнов под каждый чих B> удобно для логирования и анализа эксепшнов, потому как понятно где лежат B> тип и дополнительные параметры минусы: B> нельзя четко ловить нужное исключение B> но можно написать несколько методов для фильтрации B> например: B>
B> catch( Exception e )
B> {
B> MyExc.CheckMyExc( e, "MyTypeZZZ" ); //прокидывает эксепшн дальше, если
B> это не MyExc
B> // тут обработка того, если это действительно MyExc с типом
B> "MyTypeZZZ" }
B>
B> получается почти как на VB, где есть B> catch ... with
Что то я ничего хорошего в этом способе не вижу... Вместо того чтоб один раз написать класс исключения ты вынужден в каждом обработчике делать лишние телодвижения... Да и помещать код логгирования внутрь исключения мне как-то не нравиться.
