[C] [жизнь без исключений] Как вы обрабатываете ошибки?

С goto ресурсов понадобиться столькоже, только код будет нечитаем. Чтобы понять что у меня за ошибка я каждый раз буду лазить в конец функции.. класс:)

>> А... так ты его просто готовить не умеешь.

> Может ты не умеешь готовить нормальный алгоритм?))

Может быть. Но: 1) я не один такой 2) для того, чтобы нписать ясные goto (то есть передача управления всегда вперед, на плотно расположенные метки) не надо готовить "нормальный алгоритм".

P.S. так как насчет исключений - они нужны, или нужно готовить "нормальные алгоритмы", которые без них обойдутся?

>В Си всегда можно обойтись без goto
да, можно.

>И в 100% решение без goto будет лучше.
нет, не в 100%.

>Но вообще надо сильно извратиться, чтобы у тебя было два вложенных цикла и тебе нужнобыло выходить сразу из обоих - это причина сильно задуматься над своим алгоритмом, а не использовать goto.

Что-то делаем с большим TIFF файлом и вдруг внезапно какой-то сегмент файла не замапился в ОЗУ из-за того что есть ошибка в структуре файла (он битый). Сойдет?

> Чтобы понять что у меня за ошибка я каждый раз буду лазить в конец функции.. класс:)

Ааааа держите меня трое!!!11 %) Тебе надо "лазить" в конец функции, она на экран не помещается? И нормальных имен ты меткам дать не можешь? :D

Одна будет метка.
#define ERR(mes) \
{ \
  log((mes)); \
  goto error; \
}


func() {
  ...
  if (error) {
      ERR("error 1");
  }

error:
  ...  deallocate ...
  return;
}

Посмотри исходники крупных проектов. Исходники linux'а, bsd. Где там и что нечитаемо? Всё прекрасно читаемо. С goto код получается компактным и понятным. А без goto разрастается так, что тебе приходится "лазить в конец функции".

>P.S. так как насчет исключений - они нужны, или нужно готовить "нормальные алгоритмы", которые без них обойдутся?

Мне считай что не нужны:)

>для того, чтобы нписать ясные goto (то есть передача управления всегда вперед, на плотно расположенные метки) не надо готовить "нормальный алгоритм". 

Делашь код нечитаемым.

Пример 1:

if(func1())
{
   обработка 1
}

if(func2())
{
   обработка 2
}

if(func3())
{
   обработка 3
}

if(func4())
{
   обработка 4
}



Пример 2:

if(func1())
  goto label1;
if(func2())
  goto label2;
if(func3())
  goto label3;
if(func4())
  goto label4;

label1:
{
   обработка1;
}
label2:
{
   обработка2;
}
label3:
{
   обработка3;
}
label4:
{
   обработка5;
}

Во втором варианте мы видим жопу:)

>А без goto разрастается так, что тебе приходится "лазить в конец функции".

наоборот:) не передёргивай.

>Если в функции произошла ошибка, то безусловно при правильно проектировании будет return; break применяется для изменения поведения цикла при определённых условиях.

ужасающие вложенные fucked-циклы нам уже показали. а еще бывает, что в рамках одной функции проиходят ошибки в разных ее местах, и кроме выполнения мгновеннго return необходимо выполнить ряд действий, необходимых при любой из произошедших ошибок: очистить временно занятую функцией (ее переменными) память, закрыть сокеты, запостить в stderr отчет об ошибке, послать привет маме и т.д.

делать это в каждом if(error){} утомительно, вынести в отдельную функцию нереально (реально, но с передачей в нее кучи параметров из ошибочной функции).

>если же тебе туго без goto, то сильно задумываешься, а потом переписываешь нафиг эту часть программы

вот это я и называю чрезмерным упованием на надуманную "красоту" алгоритма.

Это вырожденный случай и в реальной жизни может встретиться только в индусокоде. В нормальном случае обработка всех ошибок в пределах одной функции делается однотипным образом.

Еще раз для тех кто в танке -- код с goto компактен и влазит на один экран, поэтому "лазить в конец функции" не нужно.

Твой пример вообще бесполезен.

бредовый код. никто, кто использует goto такое Г. не напишет. не впадай в крайности, чувак!

>В нормальном случае обработка всех ошибок в пределах одной функции делается однотипным образом.

Вот про что я и говорю:) Нафиг в таком случае не нужен никакой goto.

> Во втором варианте мы видим жопу:)

можно еще больше извратиться :)

struct funcData data;
data.p1 = ...
...

res = func1( data ) && func2( data ) && func3( data ) && func4( data );

free( data.p1 );
...

return res;


где внутри функций будет вывод ошибки

Он из реальной жизни, а вот твой точно бесполезен и высосан из пальца.

Неправильно.

Правильно так:

if (func1())
    обработка1;

if (func2()) {
    обработка2;
    обработка1;
}

if (func3()) {
    обработка3;
    обработка2;
    обработка1;
}

if (func4()) {
    обработка4;
    обработка3;
    обработка2;
    обработка1;
}

против:

if (func1())
    goto err_func1;
if (func2())
    goto err_func2;
if (func3())
    goto err_func3;
if (func4())
    goto err_func4;

return ok;

err_func4:
    обработка4;
err_func3:
    обработка3;
err_func2:
    обработка2;
err_func1:
    обработка1;
    
return err;

Так где жопа?

можно, но читабельность страдает

>бредовый код. никто, кто использует goto такое Г. не напишет. не впадай в крайности, чувак!

Топикстартер чуть выше хочет такой код:) Иначе просто функция, как в моём варианте.

>Так где жопа?
плюсую твой пример! в ядре такое очень часто встречается.

Эти варианты дадут разный результат.

Вот реальный пример:

int create_socket(const char *path, unsigned int perm, unsigned int nrlisten)
{
	struct sockaddr_un sockaddr;
	int err, fd;

	fd = socket(AF_UNIX, SOCK_STREAM, 0);
	if (fd == -1)
		goto error;

	err = fcntl(fd, F_SETFL, O_NONBLOCK);
	if (err) 
		goto error_close_sock;

	sockaddr.sun_family = AF_UNIX;
	strncpy(sockaddr.sun_path, path, sizeof(sockaddr.sun_path) - 1);

	err = bind(fd, (struct sockaddr *)&sockaddr, SUN_LEN(&sockaddr));
	if (err) 
		goto error_close_sock;

	err = chmod(path, perm);
	if (err)
		goto error_unlink_sock;

	err = listen(fd, nrlisten);
	if (err) 
		goto error_unlink_sock;

	err = check1();
	if( err ) 
		goto error_check_fail;

	err = check2();
	if( err ) 
		goto error_check_fail;

	return fd;

error_check_fail:
	check_fail();
error_unlink_sock:
	unlink(path);
error_close_sock:
	close(fd);
error:
	return -1;
}

Неправильно:) Как уже написал Reset обработки в основном однотипны, а у тебя хрень какаято:)

>Топикстартер чуть выше хочет такой код:)
бред. он не сказал, какой код он хочет))
goto можно использовать по-разному.
в каких-то случаях это будет неопавданно. как в твоем примере, в других случаях (как привел kemm) - наоборот.

>Как уже написал Reset обработки в основном однотипны, а у тебя хрень какаято:)
нихрена они не однотипны.

> можно, но читабельность страдает

разве вариант kemm:

if (func1())
    goto err_func1;
if (func2())
    goto err_func2;
if (func3())
    goto err_func3;
if (func4())
    goto err_func4;

return ok;

err_func4:
    обработка4;
err_func3:
    обработка3;
err_func2:
    обработка2;
err_func1:
    обработка1;

читабельней чем

res = 
  func1( data ) && 
  func2( data ) && 
  func3( data ) && 
  func4( data );

?

эти варианты не эквивалентны

Где же это реальный пример если при открытии сокета у тебя ошибка не обрабатываеться, а просто идёт goto на return -1 ?

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

Угу, только в func[1-4]() мы захватываем всевозможные ресурсы, которые надо освободить. Расскажи, как это сделать в твоём варианте.

Т.е. напиши, что должно идти после твоего 'res = func1() && ...;', чтобы работало ровно так, как мой вариант с goto?

>если при открытии сокета у тебя ошибка не обрабатываеться, а просто идёт goto на return -1 ?
присмотрись внимательней. там в середине есть return fd; :)
только не надо про то, что не наглядно. я вот сразу увидел

>Он из реальной жизни, а вот твой точно бесполезен и высосан из пальца.

Мой бесполезен в случае применения goto, в реальности в основном так и пишут.

> Замени сразу на нужные обработчики и будет тебе человеческий код.

Замени сам этот вариант на свой и запость, а мы оценим, который понятнее и безопаснее.

fd = socket(AF_UNIX, SOCK_STREAM, 0);
	if (fd == -1)
		goto error;

и, да, ядро не должно обрабатывать ошибку. оно должно возращать ее код :)

>> P.S. так как насчет исключений - они нужны, или нужно готовить "нормальные алгоритмы", которые без них обойдутся?

> Мне считай что не нужны:)

Хм. Подозреваю троллинг.

Алсо, твой торой вариант неэквивалентен первому - у тебя возврат функциями не-0 то считается нормальным завершением, то ошибкой.

>Замени сам этот вариант на свой и запость, а мы оценим, который понятнее и безопаснее.
+1. "человеческий" код в студию)

> Т.е. напиши, что должно идти после твоего 'res = func1() && ...;', чтобы работало ровно так, как мой вариант с goto?

ну очевидно же - в func1, например, пишем data.buffer = malloc..., или data.ifile = fopen( ... ), а в конце "после моего 'res =...":

free( data.buffer );
free( data.tiff_rows );
if( fdata.ifile ) fclose( fdata.ifile );
...

>и, да, ядро не должно обрабатывать ошибку. оно должно возращать ее код :)
точнее, должно, но в данном случае ничего более return -1 не требуется

а если data.tiff_rows не была выделена? (например, она выделяется в func2, а func1 сразу вернула ошибку)
SEGFAULT

Наконец-то хороший goto-срач

int create_socket(const char *path, unsigned int perm, unsigned int nrlisten)
{
	struct sockaddr_un sockaddr;
	int err, fd;

	if((fd = socket(AF_UNIX, SOCK_STREAM, 0)) < 0)
	     return -1;

	if(fcntl(fd, F_SETFL, O_NONBLOCK) < 0)
	     error_close_sock;

	sockaddr.sun_family = AF_UNIX;
	strncpy(sockaddr.sun_path, path, sizeof(sockaddr.sun_path) - 1);

	if(bind(fd, (struct sockaddr *)&sockaddr, SUN_LEN(&sockaddr)) < 0)
             error_close_sock;

	if(chmod(path, perm) < 0)
	     error_unlink_sock;

	if(listen(fd, nrlisten) < 0)
	     error_unlink_sock;

	if(check1() < 0)
	    error_check_fail;

	if(check2() < 0)
	    error_check_fail;

	return fd;

}

> а если data.tiff_rows не была выделена? (например, она выделяется в func2, а func1 сразу вернула ошибку)
> SEGFAULT

free( NULL ) - это не SEGFAULT

П.С. да - я всегда обнуляю все указатели

>Наконец-то хороший goto-срач

кому надо сказать спасибо? :)

запостил

Ну и что значат эти твои error_*?

> error_close_sock;
> error_close_sock;
> error_unlink_sock;
> error_unlink_sock;
> error_check_fail;
> error_check_fail;
что это за фигня? реальный код на Си, плиз!!

>free( NULL ) - это не SEGFAULT
а ты гарантируешь, что в data.tiff_rows будет NULL?

>кому надо сказать спасибо?
людям, впадающим в крайности

Э, нет. Что такое error_.*? Рабочий код на C, пазалуста!

Угу. А если там не malloc()? А если мы там с железкой работаем, и для правильной работы надо что-нибудь куда-нибудь записать в случае ошибки (и никогда больше)?

Сферические кони в вакууме такие сферические...