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

Разберем на конкретном примере. Вот пишу я простенькую программу на C++ с использованием  WinAPI. Хочу в ней сделать простое действие - поменять текст на кнопке, делается это просто вызовом функции SetWindowText(хандл, текст). 

Функция то простецкая, да вот засада она возвращает флаг  результата выполнения операции. Ну чтож думаю дай посмотрю что может быть каверзного при смене заголовка, если произошла ошибка то надо вызвать GetLastError смотрим её описание она используется при всех ошибках, и имеет 50000 тыс кодов ошибок, понятно что искать которые потенциально могут относиться к смене текста бесполезно, тогда предполагаем что такие ошибки есть. И что нам теперь делать? Проверять каждый раз результат операции, если неудачный то генерить исключение и выходить посредством его из программы..? 

Получается какая то параноя, может тупо забить на это, предполагая нереальность данной ситуации? Может стоит обрабатывать только реально потенциальные ошибки, например нехватка бумаги в принтере при печати, несущ файла...? 
Вот и выходит какая то параноя. А как пишите Вы, уважаемые кодеры, пусть не на C++  и не на WinAPI, это просто пример.

М... просмотры есть, ответов нет... Странно, неужели все просто не рассматривают данный вопрос, или просто не ту ветку выбрал, может в другое место форума запостить    ?

обработка ошибок пишется там где могут быть ошибки.

Добавлено через 3 минуты и 19 секунд
SetWindowText может вернуть 1 ошибку - неправильный хендл
если Вы уверены что хендл правильный проверять не надо.
если допускаете что он может быть неправильным - проверять надо
при этом, максимум что случится - текст не будет задан. пользователь это заметит и напишет багрепорт

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

зависит от программы... и требований к ней.
Лучший вариант: перейди на любой современный язык программирования и забудь про ручное управление выделением памяти.

Добавлено через 2 минуты и 6 секунд

Что тут странного? Покажи мне хотя бы одну тему, в которой количество просмотров совпадает с количеством ответов.

raznodel, если ты можеш справиться с ошибкой выделения памяти (своя выделялка и т.п.) - пиши обработчик
если не можешь - пиши сообщение "program died" и пиши ошибку в лог чтобы юзер мог тебе отправить этот лог, и ты пофиксил бы ошибку в следующей версии программы, если это ошибка программы, а не попытка юзера выделить памяти больше чем доступно на его машине

Добавлено через 2 минуты и 33 секунды
source777, представь себе, в некоторых современных языках программирования, нет автоматического выделения памяти.
что характерно во многих устаревших языках программирования, оно было. 
нет никакой связи между управлением памятью и современностью языка программирования.

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

source777, "новый" не равно "современный"
современный - это тот, который сейчас активно используется и развивается

однако,
С99 не старше 15 лет, последний стандарт был в 99 году, в никсах на С пишут не меньше чем на С++
С++03  не старше 15 лет, последний стандарт был в 2003 году, готовится новый стандарт, постоянно обновляются компиляторы и т.п.
D совсем новый язык, впрочем непопулярный, потому что о нем никто не знает
дельфи тоже еще живет, в 2009 в нее вроде лямбды добавили о_О
в определенных отраслях писали и пишут исключительно на асме.

-------------------------------------------------------------------------------------------------------------------------------
на счет ручного управления памятью.
ручное выделение памяти важно в программах, критичных к объему памяти. Если программа потребляет всю физическую или виртуальную память, без ручного управления памятью не обойтись, также не обойтись без легковесных структур данных, чего нет например в современной (?) java
также при создании большого количества мелких объектов, рекомендуется использовать собственные средства выделения памяти, т.к. стандартные на это не рассчитаны, само собой тут уже никакой язык не поможет.

на счет ошибок выделения памяти.
автоматическое управление памятью никак не спасет от ошибки при выделении памяти, и скорей всего никак не позволит обработать эту ошибку.
если в win32 приложению доступно только 2Гб виртуальной памяти, никакой язык с автоматическим выделением памяти не может выделить 2.1Гб

Добавлено через 3 минуты и 7 секунд
source777, ТС спросил "что делать при нехватке памяти"
как современный язык программирования с автоматическим управлением памятью поможет от нехватки памяти?

это уже другой философский вопрос. Если язык программирования в своём развитии следует принципу обратной совместимости, то он постепенно морально устаревает. Это можно наблюдать на примере и С++ и Delphi. Что бы не говорили их фанаты... С++ уже стал нишевым языком, а Delphi так вообще поспособствовал банкротству самой Borland. 
Да, сейчас предпринимаются некоторые шаги по реанимации этих языков, портируются фичи из тех же .NET и Java. Но мне все эти попытки видятся недальновидными, т.к. роль догоняющего в данном вопросе бесперспективна.
Кстати, fyi: Delphi не всегда требует ручного управления памятью, издревле там есть рефкаунтинг через интерфейсы.


ну и что, в определённых отраслях до сих пор MS DOS используют, это не повод считать её современной ОС.



Ну, во-первых, 10 лет это уже не "совсем новый". А во-вторых, D использует сборщик мусора и уж точно не требует ручного управления памятью.


смотря с чем связана ошибка: с тем что реально не хватает памяти или с memory leaks. Первое уже становится фантастической ситуацией для большинства приложений, а второе практически исключается наличием сборщика мусора.
Но даже в крайнем случае получить разумное исключение гораздо приятнее, чем просто код ошибки.



ТС спрашивал про "ошибки выделения памяти", которые не всегда связаны с её реальной нехваткой.

никто собственно обратного и не утверждал, но речь изначально шла о WinAPI, а кому придёт в голову ставить Windows на оборудование(про ПК в данном контексте и речи быть не может), в котором важна экономия ресурсов?


P.S. 5 ЯП ты назвал, но только 3 из них реально требуют ручного управления памятью(asm, C, C++) + ни один из этих трёх нельзя назвать современным(учитывая что у самого молодого из них уже 30-летняя история), так что незачёт.
  

source777, 
есть подозрение, что твои "современные" "мейнстримовые" языки, позволяют решать только задачи типа "найти сумму двух чисел" и требуют при этом немалое количество ресурсов.

назови хоть один (а не 5) "современный" "мейнстримовый" язык который например позволял бы работать с матрицами из десятков миллионов элементов?
я что-то плохо себе представляю ansys или nastran написанный на джаве или C#

т.е. на каком современном языке можно решать ресурсоемкие задачи?

чтобы работать с матрицами есть MatLab, J, Octave, etc., нет смысла подстраивать язык общего назначения под узкоспециализированную программу и дело тут отнюдь не в производительности мейнстрим языков (тот же C# в среднем всего на 30% медленнее С++, при условии что С++ программа скомпилирована из исходников), дело в том, что под каждую задачу нужно выбирать язык, который для этой задачи подходит лучше других. Я не отрицаю, что и для С++ до сих пор есть такие задачи, но их число год от года стремительно сокращается.
Если есть сильное желание всё же использовать мейнстрим языки для математических задач, то можно спокойно использовать Haskell, Python + NumPy + SciPy, C# + Numerical components + Math.NET, и даже в крайнем случае Java + JMathTools.


конечно, сложно представить, чтобы в 60-70-ые годы их начали писать на несуществующих в то время языках.



ресурсоёмкие задачи тоже бывают разные, про математические я написал выше...
Кроме того ресурсоёмкие задачи принято решать на уровне алгоритма, а конкретный язык реализации, как правило, уже не столь важен. Т.к. на уровне алгоритма можно получить ускорение в десятки и даже тысячи раз, а при переписывании, к примеру, с Java на С в самом крайнем случае в 2-3 раза.

что такое "в среднем" и откуда такое число?

под ресурсоемкостью я имел в виду объем памяти, не только скорость выполнения операций.
есть статистика, во сколько раз больше требуется памяти в Haskell, Python, C# или Java по сравнению с С++?

Да это на RSDN давно измеряли(сейчас разница будет ещё меньше), а "в среднем" значит по результатам всех тестов.



Тут никакой статистики быть не может, во-первых, сильно зависит от задачи, во-вторых, непонятно с чего ты взял что памяти требуется больше? Тут в общем-то чем серьёзней задача, тем меньше разница.

Добавлено через 1 минуту и 46 секунд
P.S. топикстартер вообще исчез, так что закончим на этом оффтопик.