Return values
От: Воронков Василий Россия  
Дата: 27.04.04 07:46
Оценка:
Последнее время "подсел" на следующую манеру письма. например:

if (some_condition)
    return true;
else
    return some_error();


private bool some_error()
{
    //processing an error
    return false;
}


Т.е. получаются методы всегда возвращающие какое-то одно значение. Все это конечно указывается в комментариях и замечаний мне никто не делал, но насколько это нормально на ваш взгляд? Мне лично нравится сам подход типа return some_error(), т.к. по идее по коду понятно, что именно будет возвращено и тело основного метода не загромождается.
Posted via RSDN NNTP Server 1.8

07.05.04 14:42: Перенесено модератором из '.NET' — TK
Re: Return values
От: Андрей Майоров Россия http://blogs.byte-force.com/xor
Дата: 27.04.04 08:27
Оценка: 1 (1) +2 -1
Здравствуйте, Воронков Василий, Вы писали:

А что конкретно подразумевается под:
ВВ>    //processing an error


Например, какое-нибудь логирование? Тогда, ИМХО, лучше сделать метод ProcessSomeError(), а после его вызова явным образом вернуть false. У меня от строки
    return some_error();

складывается ощущение, что функция some_error создает какой-то объект ошибки и возвращает его. Понятно, что тип возвращаемого значения у нее bool и ничего другого вернуть она не может, но ощущение есть.

WBR,
XOR // BYTE-force
... << RSDN@Home 1.1.3 stable >>
WBR,
XOR // BYTE-force
Re: Return values
От: Tom Россия http://www.RSDN.ru
Дата: 27.04.04 09:11
Оценка: 28 (3) +3 -1
ВВ>Т.е. получаются методы всегда возвращающие какое-то одно значение. Все это конечно указывается в комментариях и замечаний мне никто не делал, но насколько это нормально на ваш взгляд? Мне лично нравится сам подход типа return some_error(), т.к. по идее по коду понятно, что именно будет возвращено и тело основного метода не загромождается.

Такой подход IMHO есть плохо, так как не использует исключений. Они для того и придуманы, что бы так не писать. По нормальному обработку ты должен делать где то скажем в конструкторе исключения. А методы, возвращающие результат были нужны только когда не было возможности пользоваться исключениями. Например так сделано в COM-ме. Возвращается HRESULT.
... << RSDN@Home 1.1.0 stable >>
Народная мудрось
всем все никому ничего(с).
Re[2]: Return values
От: Воронков Василий Россия  
Дата: 27.04.04 10:48
Оценка: +1
"Tom" <3627@news.rsdn.ru> wrote in message news:620858@news.rsdn.ru...

> Такой подход IMHO есть плохо, так как не использует исключений. Они для того и придуманы, что бы так не писать. По нормальному обработку ты должен делать где то скажем в конструкторе исключения. А методы, возвращающие результат были нужны только когда не было возможности пользоваться исключениями. Например так сделано в COM-ме. Возвращается HRESULT.


Вообще пример с some_error был довольно условный — чтобы показать сам принцип. К тому же ошибка — это не есть исключение. Я вот не вижу оснований бросать исключение, если можно прекрасно обойтись без него, учитывая что процесс генерации исключения штука довольно "дорогая". рассмотрим например вариант, когда приложение при старте загружает подключаемые модули. Допустим, один из модулей, наличие которого совершенно не критично, не смог загрузиться. Все что мне нужно — это сделать запись в лог о невозможности загрузить такой-то модуль. зачем в данном случае исключение-то бросать?
Posted via RSDN NNTP Server 1.8
Re[3]: Return values
От: mikа Stock#
Дата: 27.04.04 11:00
Оценка: 14 (2) +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вообще пример с some_error был довольно условный — чтобы показать сам принцип. К тому же ошибка — это не есть исключение. Я вот не вижу оснований бросать исключение, если можно прекрасно обойтись без него, учитывая что процесс генерации исключения штука довольно "дорогая". рассмотрим например вариант, когда приложение при старте загружает подключаемые модули. Допустим, один из модулей, наличие которого совершенно не критично, не смог загрузиться. Все что мне нужно — это сделать запись в лог о невозможности загрузить такой-то модуль. зачем в данном случае исключение-то бросать?


Я, конечно, не вижу все твою проблему в целом, но тут использование исключений как нельзя кстати. Бросить исключнение — это не значит, что нужно прервать обработку. Почему бы после ошибки тебе не продолжить подгузку модулей? Кстати, подгрузка модулей случаем не Assebmly.Load? Если да, то говорить о "дороговизне" исключений как-то не уместно.

Вообщем, данный пример не катит. Давай еще
Re[4]: Return values
От: Воронков Василий Россия  
Дата: 27.04.04 11:29
Оценка:
"mikа" <5481@news.rsdn.ru> wrote in message news:621017@news.rsdn.ru...

> Я, конечно, не вижу все твою проблему в целом, но тут использование исключений как нельзя кстати.


Чем же она так кстати?

>Бросить исключнение — это не значит, что нужно прервать обработку.


Ну да, try/catch рулит

>Почему бы после ошибки тебе не продолжить подгузку модулей?


А зачем? Т.е. я на твой взгляд должен делать что-то типа:

try
{
    Type t = Type.GetType(typeName, true);
}
catch (DontRememberException)
{
    //continue to work
}


вместо

Type t = Type.GetType(typeName);

if (t == null)
   //report about error.


А зачем? Какой смысл?

>Кстати, подгрузка модулей случаем не Assebmly.Load? Если да, то говорить о "дороговизне" исключений как-то не уместно.


Кстати, исключение генерируется еще медленнее. Да и потом если основной механизм подгрузки модулей через рефлекшин и так не особо быстрый, то зачем еще дополнительные тормоза придумывать?

> Вообщем, данный пример не катит. Давай еще


Ну вообще все началось с такого сценария. Пишется некий метод DoSmth, на первоначальном этапе его реализации он не может провалится, т.е. результат всегда будет true. Но в будущем возможно появится такое условие, из-за которого он может вернуть false. Поэтому я пишу

bool DoSmth()
{
    //some shit
    return true;
}


Потом стал делать независимо от того, будет ли меняться реализация DoSmth в будущем или нет. Т.е. в итоге все выглядит так:

public bool RegisterSomeShit()
{
    if (/*уже зарегистрировано*/)
        return false;
    else
        return DoSmth();
}


Вот я и спрашиваю насколько это плохо. Т.е., говоря обобщенно, насколько плохо писать методы возвращающие всегда одно и то же значение.
Posted via RSDN NNTP Server 1.8
Re[5]: Return values
От: mikа Stock#
Дата: 27.04.04 11:39
Оценка: 18 (1) +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Чем же она так кстати?


Ниже.

ВВ>Ну да, try/catch рулит


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

>>Почему бы после ошибки тебе не продолжить подгузку модулей?


ВВ>А зачем? Т.е. я на твой взгляд должен делать что-то типа:


ВВ>
ВВ>try
ВВ>{
ВВ>    Type t = Type.GetType(typeName, true);
ВВ>}
ВВ>catch (DontRememberException)
ВВ>{
ВВ>    //continue to work
ВВ>}
ВВ>


Почему DontRememberException? Ты же его в лог пишешь. Или потом в массив закидываешь и генеришь уже свое исключение, состоящее из этого массива. Таким образом ты отделишь уровни логирования и подгрузки модулей.

ВВ>вместо


ВВ>
ВВ>Type t = Type.GetType(typeName);

ВВ>if (t == null)
ВВ>   //report about error.
ВВ>


ВВ>А зачем? Какой смысл?


Что значит null? Не найдена сборка, не найден тип, передана пустая строка или невалдная строка? С своем null ты ничего не узнаешь.

>>Кстати, подгрузка модулей случаем не Assebmly.Load? Если да, то говорить о "дороговизне" исключений как-то не уместно.


ВВ>Кстати, исключение генерируется еще медленнее. Да и потом если основной механизм подгрузки модулей через рефлекшин и так не особо быстрый, то зачем еще дополнительные тормоза придумывать?


Вот я и говорю, что подгрузка, допустим, занимает 99 процентов времени, а исключение 1. Разницы никакой.

>> Вообщем, данный пример не катит. Давай еще


ВВ>Ну вообще все началось с такого сценария. Пишется некий метод DoSmth, на первоначальном этапе его реализации он не может провалится, т.е. результат всегда будет true. Но в будущем возможно появится такое условие, из-за которого он может вернуть false. Поэтому я пишу


ВВ>Вот я и спрашиваю насколько это плохо. Т.е., говоря обобщенно, насколько плохо писать методы возвращающие всегда одно и то же значение.


В грамах ответить не могу, на сколько это плохо, но плохо. Если тебе нужна какая-то регистрационная информация об ошибках (создавать свои коды ошибок), то тут исключения подходят на 100 процентов (не забываем, что это простой класс).
Re[3]: Return values
От: Tom Россия http://www.RSDN.ru
Дата: 27.04.04 12:03
Оценка:
ВВ>Вообще пример с some_error был довольно условный — чтобы показать сам принцип. К тому же ошибка — это не есть исключение. Я вот не вижу оснований бросать исключение, если можно прекрасно обойтись без него, учитывая что процесс генерации исключения штука довольно "дорогая". рассмотрим например вариант, когда приложение при старте загружает подключаемые модули. Допустим, один из модулей, наличие которого совершенно не критично, не смог загрузиться. Все что мне нужно — это сделать запись в лог о невозможности загрузить такой-то модуль. зачем в данном случае исключение-то бросать?

Для того, что бы в классе исключения ты мог указать какая сборка и почемук не загрузилась. А потом в методе загрузки ты можешь спокойно перехватить это исключение и записать в лог скажем ex.ToString(). Это будет красиво. По поводу быстродействия:
1. Любую идею можно довести до маразма
2. Раз ты уж пишешь на .NET то быстродействия явно не основная причина
... << RSDN@Home 1.1.0 stable >>
Народная мудрось
всем все никому ничего(с).
Re[3]: Return values
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.04.04 15:24
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>учитывая что процесс генерации исключения штука довольно "дорогая".


Это миф.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[4]: Return values
От: Воронков Василий Россия  
Дата: 27.04.04 16:51
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>2. Раз ты уж пишешь на .NET то быстродействия явно не основная причина


Вот это точно миф
... << RSDN@Home 1.1.3 stable >>
Re: Return values
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.04.04 23:03
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Т.е. получаются методы всегда возвращающие какое-то одно значение. Все это конечно указывается в комментариях и замечаний мне никто не делал, но насколько это нормально на ваш взгляд? Мне лично нравится сам подход типа return some_error(), т.к. по идее по коду понятно, что именно будет возвращено и тело основного метода не загромождается.


По фигу, еслитебе так удобнее. Главное, чтобы была продуманная идеология обработки ошибок.
... << RSDN@Home 1.1.3 beta 2 >>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Return values
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.04.04 23:03
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Это миф.


Это не миф. Это относительная величина. По сравнению с ифом или брэйком это невероятно долгая операция, но по сравнению с методом обработки уже нет.

К тому же под отладкой первое исключение действительно сильно тормозит.
... << RSDN@Home 1.1.3 beta 2 >>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Return values
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.04.04 23:03
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>2. Раз ты уж пишешь на .NET то быстродействия явно не основная причина


Лет 7 назад я слышал такую же пургу про С++.
... << RSDN@Home 1.1.3 beta 2 >>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Return values
От: IT Россия linq2db.com
Дата: 30.04.04 03:31
Оценка: 1 (1) +3
Здравствуйте, VladD2, Вы писали:

ВВ>>Т.е. получаются методы всегда возвращающие какое-то одно значение. Все это конечно указывается в комментариях и замечаний мне никто не делал, но насколько это нормально на ваш взгляд? Мне лично нравится сам подход типа return some_error(), т.к. по идее по коду понятно, что именно будет возвращено и тело основного метода не загромождается.


VD>По фигу, еслитебе так удобнее. Главное, чтобы была продуманная идеология обработки ошибок.


По фигу — это если у тебя приложение такой же хэллоу-вёрд как привёл ВВ.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re: Return values
От: IT Россия linq2db.com
Дата: 30.04.04 03:31
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Т.е. получаются методы всегда возвращающие какое-то одно значение. Все это конечно указывается в комментариях и замечаний мне никто не делал, но насколько это нормально на ваш взгляд? Мне лично нравится сам подход типа return some_error(), т.к. по идее по коду понятно, что именно будет возвращено и тело основного метода не загромождается.


А какую полезную информацию сообщит твой код вызывающей программе, кроме собственно "Ну, не шмагла я, не шмагла!"?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Return values
От: Воронков Василий Россия  
Дата: 30.04.04 06:30
Оценка:
"IT" <1@news.rsdn.ru> wrote in message news:624796@news.rsdn.ru...

> А какую полезную информацию сообщит твой код вызывающей программе, кроме собственно "Ну, не шмагла я, не шмагла!"?


Что вы все на ошибках зациклились? Я просто пример привел, может, и неудачный. Суть вопроса в другом была. А получается, мы теперь обсуждаем, нужно ли генерировать исключение всякий раз когда возникает ошибка.

Касательно того, какую информацию сообщит — здесь ситуация такая. Есть загрузчик системы, сам по себе загрузчик системы не может знать какая из ошибок, возникающая в процессе загрузки, является критической. Поэтому его задача сводится лишь к тому, чтобы при возникновении ошибки загрузки прописать в лог, какой модуль не смог загрузиться. А после загрузки уже происходит анализ состояния системы и, если нужно, генерируется исключение, прекрающее работу приложения. И в данном случае я не вижу никакого смысла в том, чтобы загрузчик при возникновении ошибок генерировал исключения, и тут же сам их перехватывал.
Posted via RSDN NNTP Server 1.8
Re[5]: Return values
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.04.04 07:45
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Это не миф. Это относительная величина. По сравнению с ифом или брэйком это невероятно долгая операция, но по сравнению с методом обработки уже нет.


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

VD>К тому же под отладкой первое исключение действительно сильно тормозит.


Ну и что?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[3]: Return values
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.04.04 07:55
Оценка: 9 (2)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Что вы все на ошибках зациклились? Я просто пример привел, может, и неудачный. Суть вопроса в другом была. А получается, мы теперь обсуждаем, нужно ли генерировать исключение всякий раз когда возникает ошибка.


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

ВВ>Касательно того, какую информацию сообщит — здесь ситуация такая. Есть загрузчик системы, сам по себе загрузчик системы не может знать какая из ошибок, возникающая в процессе загрузки, является критической. Поэтому его задача сводится лишь к тому, чтобы при возникновении ошибки загрузки прописать в лог, какой модуль не смог загрузиться. А после загрузки уже происходит анализ состояния системы и, если нужно, генерируется исключение, прекрающее работу приложения.


То есть исключения должны генерится только для прекращения работы системы, а catch вобще надо запретить?

ВВ> И в данном случае я не вижу никакого смысла в том, чтобы загрузчик при возникновении ошибок генерировал исключения, и тут же сам их перехватывал.


А я вот вижу — во-первых я не буду в дальнейшем заморачиваться над тем на каком уровне мне ошибочную ситуацию определять и на каком уровне обработать, не нужно передавать из метода в метод через сигнатуру результат работы. Во-вторых если я забуду обработать то сразу это увижу, причем не буду искать причины проишедшего, все сразу понятно. В-третьих исключение не позволит логике работать неверно из-за того что я забыл обработать ситуацию незагрузки модуля. В-четвертых, как правильно заметил IT, исключение несет значительно больше информации. Писать в лог что модуль не загрузился это конечно здорово, но было бы интересно знать по какой причине. Наконец в-пятых исключение позволит тебе одним кодом обработать как ошибки в твоем коде, так и ошибки, произошедшие внутри фреймворка (файл например не найден). Т.е. в твоем варианте все равно возможно исключение, которое ты не предусмотрел и оно вызовет крах твоей системы, несмотря на то что это ошибка загрузки конкретного модуля.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[4]: Return values
От: Воронков Василий Россия  
Дата: 30.04.04 08:07
Оценка: :)
"AndrewVK" <5161@news.rsdn.ru> wrote in message news:625100@news.rsdn.ru...

> То есть исключения должны генерится только для прекращения работы системы, а catch вобще надо запретить?

>
> ВВ> И в данном случае я не вижу никакого смысла в том, чтобы загрузчик при возникновении ошибок генерировал исключения, и тут же сам их перехватывал.

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

try
{
    ...
    if (some_condition)
        throw new Exception(...);
}
catch(Exception e)
{
    ...
}


Для того, чтобы узнать причину по которой не загрузился модуль, мне исключения _генерировать_ не обязательно. Стандартные исключения я и так обрабатываю. Просто при возникновении ошибки при загрузке я исключение не генерирую. А ошибкой может быть например следующее — модуль успешно загружен, но не реализует такой-то нужный интерфейс и пр.
Posted via RSDN NNTP Server 1.8
Re[5]: Return values
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.04.04 08:25
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Я тебе вроде как привел причины. Большинство из них вполне соответствуют и этой ситуации.

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


Ну и какой смысл еще и код возврата прикручивать? Две дырки для одного и того же? И как сообщение об ошибке в лог попадет?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.