The motivation for these macros is to refactor code like:

if (success)
if (success)
if (success)
...

into

try {
if (error) throw;
if (error) throw;
if (error) throw;
...
} catch {
}

Where macros are

#define try if (1)
#define catch else catch_label:
#define throw goto catch_label

When I asked "do you like this macro" the feedback was 100% negative.

After using this macro in a real program with 131 try-catch blocks I
counted the number of empty catch blocks. In 80% of cases
the catch block was empty.

So, basically ,in 80% of cases I can replace the macros just for
goto exit.

if (error) goto exit;
if (error) goto exit;
if (error) goto exit;
....

exit:

Making the macro useless.
(I think this is OK, even using goto)

I created this post to ask about alternatives for this 20% reaming
cases where I actually have used the catch block.

The direct alternative is:

if (error) goto error;
if (error) goto error;

....

if (0) error: {
/*code executed only when error is present*/
}

But it is ugly. Isn't it?

Most usages of catch block were like this:

void list_push(list* list, item)
{ try {
if (error) throw;
if (error) throw;
if (error) throw;
}
catch {
/*we cannot add item into the list*/
free(item);
}
} struct X* load(const char* filename)
{ struct X* p = ..;
try {
if (error) throw;
if (error) throw;
if (error) throw;
}
catch {
free(p);
p = NULL;
}
return p;
} void F(){
try {
if (error) throw;
if (error) throw;
if (error) throw;
}
catch {
log("error at F");
}
}

Alternatives?

void list_push(list* list, item)
{ if (error) goto onerror;
if (error) goto onerror
if (error) goto onerror
...

return;

onerror:
free(item);
} I also find this return ugly, seems to be "lost".

void F(){
try {
if (error) {log("error at F"); goto exit;}
if (error) {log("error at F"); goto exit;}
if (error) {log("error at F"); goto exit;}
}

exit:
}

This is repetitive

Would try-catch macro be a better alternative in this 20%
reaming cases?

On Wednesday, May 10, 2023 at 9:04:51 AM UTC-3, Thiago Adams wrote:
> The motivation for these macros is to refactor code like:
>
> if (success)
> if (success)
> if (success)
> ...
Formatting of the code was lost. Like this
if (success)
{ ..... if (success)
.....{
.........if (success)
.........{
.........}
......}
}

On Wednesday, May 10, 2023 at 1:04:51 PM UTC+1, Thiago Adams wrote:
> The motivation for these macros is to refactor code like:
>
> if (success)
> if (success)
> if (success)
> ...
>
> into
>
> try {
> if (error) throw;
> if (error) throw;
> if (error) throw;
> ...
> }
> catch {
> }
>
> Where macros are
>
> #define try if (1)
> #define catch else catch_label:
> #define throw goto catch_label
>
> When I asked "do you like this macro" the feedback was 100% negative.
>
> After using this macro in a real program with 131 try-catch blocks I
> counted the number of empty catch blocks. In 80% of cases
> the catch block was empty.
>
> So, basically ,in 80% of cases I can replace the macros just for
> goto exit.
>
>
> if (error) goto exit;
> if (error) goto exit;
> if (error) goto exit;
> ...
>
> exit:
>
> Making the macro useless.
> (I think this is OK, even using goto)
>
> I created this post to ask about alternatives for this 20% reaming
> cases where I actually have used the catch block.
>
> The direct alternative is:
>
> if (error) goto error;
> if (error) goto error;
>
> ...
>
> if (0) error: {
> /*code executed only when error is present*/
> }
>
> But it is ugly. Isn't it?
>
> Most usages of catch block were like this:
>
> void list_push(list* list, item)
> {
> try {
> if (error) throw;
> if (error) throw;
> if (error) throw;
> }
> catch {
> /*we cannot add item into the list*/
> free(item);
> }
> }
> struct X* load(const char* filename)
> {
> struct X* p = ..;
> try {
> if (error) throw;
> if (error) throw;
> if (error) throw;
> }
> catch {
> free(p);
> p = NULL;
> }
> return p;
> }
> void F(){
> try {
> if (error) throw;
> if (error) throw;
> if (error) throw;
> }
> catch {
> log("error at F");
> }
> }
>
>
>
> Alternatives?
>
> void list_push(list* list, item)
> {
> if (error) goto onerror;
> if (error) goto onerror
> if (error) goto onerror
> ...
>
> return;
>
> onerror:
> free(item);
> }
> I also find this return ugly, seems to be "lost".
>
> void F(){
> try {
> if (error) {log("error at F"); goto exit;}
> if (error) {log("error at F"); goto exit;}
> if (error) {log("error at F"); goto exit;}
> }
>
> exit:
> }
>
> This is repetitive
>
> Would try-catch macro be a better alternative in this 20%
> reaming cases?

How about something like:

if (error) goto exit;
if (error) goto exit;
if (this_error) goto handle_error;

....

handle_error:

// stuff here

exit:

On Wednesday, May 10, 2023 at 10:06:52 AM UTC-3, Paul N wrote:
....
> > Would try-catch macro be a better alternative in this 20%
> > reaming cases?
> How about something like:
> if (error) goto exit;
> if (error) goto exit;
> if (this_error) goto handle_error;
>
> ...
>
> handle_error:
>
> // stuff here
>
> exit:

Not sure if I understood. but in any error I want to use the same
error routine that is executed only if some error happens.
But you gave another idea.

if (error) goto error;
if (error) goto error
if (error) goto error
/*sucess*/
goto exit;

error:
...
exit:
....

that is a variation of return instead of goto exit;

On Wednesday, May 10, 2023 at 9:04:51 AM UTC-3, Thiago Adams wrote:
> Would try-catch macro be a better alternative in this 20%
> reaming cases?

Typos
reaming

should be

remaining

sorry

On Wednesday, 10 May 2023 at 17:29:51 UTC+3, Thiago Adams wrote:
> On Wednesday, May 10, 2023 at 9:04:51 AM UTC-3, Thiago Adams wrote:
> > Would try-catch macro be a better alternative in this 20%
> > reaming cases?
> Typos
> reaming
>
> should be
>
> remaining
>
> sorry

The throw and catch are bad replacement for if and
else (and are also bad replacement to goto and label). The if
and else (and very occasionally goto and label) are lot easier
tools for branching within a function.

Idea of throw is to give up whole operation regardless of
how deep in call stack you figured that there is show stopper
obstacle to its completion. Idea of catch is to then handle the
situation by handling it. Handling is typically rolling everything
back to situation before start of operation , reporting
it and giving up or trying to fix whatever caused the show
stopper and retrying the operation, or trying some less fragile
alternative.

You talk about empty catch blocks. So catching without handling?
I do not know who writes that kind of code and what is the point
of it. Unreliable software that occasionally fails but does nothing
about it and results with incorrect situation in unpredictable
ways and for unknown reasons?

* Thiago Adams <thiago.adams@gmail.com>:
> /*sucess*/
> goto exit;

This should almost always be unnecessary if you both keep your functions
small (one aspect, one function) and initialized any variable used for
resources. If you want to add e.g. some logging, you could even add e.g.
some variable for that. Something like:

#v+
{ File *file = 0;
void *hdl = 0;
const char *errstr = 0;

/* do stuff */

if (!(file = fopen("foobar", "r"))
{
errstr = "error opening foobar";
goto done;
}

/* do more stuff */

done:
if (errstr)
{
Log(errstr);
if (file) fclose(file);
if (hdl) destroy(hdl);
return -1;
}
return 0;
} #v-

And if you don't need/want logging, some 'int rc' initialized to -1 and
changed to 0 on success comes handy.

IMHO, really keep "exceptions" out, even more so if just mimicking them
(poorly) ... a real exception would unroll the stack, you'd need
setjmp()/longjmp() to get somewhat close to that.

--
Dipl.-Inform. Felix Palmen <felix@palmen-it.de> ,.//..........
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231

On Thursday, May 11, 2023 at 2:51:23 PM UTC-3, Öö Tiib wrote:
> On Wednesday, 10 May 2023 at 17:29:51 UTC+3, Thiago Adams wrote:
> > On Wednesday, May 10, 2023 at 9:04:51 AM UTC-3, Thiago Adams wrote:
> > > Would try-catch macro be a better alternative in this 20%
> > > reaming cases?
> > Typos
> > reaming
> >
> > should be
> >
> > remaining
> >
> > sorry
> The throw and catch are bad replacement for if and
> else (and are also bad replacement to goto and label). The if
> and else (and very occasionally goto and label) are lot easier
> tools for branching within a function.
>
> Idea of throw is to give up whole operation regardless of
> how deep in call stack you figured that there is show stopper
> obstacle to its completion. Idea of catch is to then handle the
> situation by handling it. Handling is typically rolling everything
> back to situation before start of operation , reporting
> it and giving up or trying to fix whatever caused the show
> stopper and retrying the operation, or trying some less fragile
> alternative.

The idea is local jumps only (not as a limitation but as a desired feature),
The names try-catch were chosen because I could find better names.

>
> You talk about empty catch blocks. So catching without handling?
> I do not know who writes that kind of code and what is the point
> of it. Unreliable software that occasionally fails but does nothing
> about it and results with incorrect situation in unpredictable
> ways and for unknown reasons?

catch block is a region of code that is executed only if we
throw (jump into it – name is bad)

The reason 80% had empty catch blocks is because throw was used only to
jump out of try-block, but I didn't need to execute anything extra
on catch block.

So, in this case the feature is similar of just using

if (error) goto exit;
if (error) goto exit;
if (error) goto exit;
exit:

But (I am again) considering an advantage of try blocks.
Because generally, the pattern I use is:

struct Resource * p1 = 0;
struct Resource* p2 = 0;
try {
if (error) throw;
if (error) throw;
} catch{}
ReleaseResource(p1);
ReleaseResource(p2);

Becase I release resources outside the try block I need to declare
out of the try block. Initially I thought this was a disadvantage
because I cannot declare and initialize at the same line.

But later I realized if we jump we need to make sure all variables are
initialized with empty states.
I cannot do this for instance:

struct Resource * p1 = ...;
if (error) goto exit;

struct Resource* p2 = ...;
if (error) goto exit;

exit:

ReleaseResource(p1);

ReleaseResource(p2);

Because p2 would be uninitialized.
The workaround is creating states
struct Resource * p1 = ...;
if (error) goto clear_p1;

struct Resource* p2 = ...;
if (error) goto clear_p2_and_p1;

clear_p2_and_p1:
ReleaseResource(p2);

clear_p1:
ReleaseResource(p1);

But this kind of code is a source of bugs in case we have 3 or
more states.

The other reason I found a advantage of try is very simple, it
creates a identation with the block and to see the destination of
throw is just following the identation. (IDEs also can close blocks)
and compared with goto the is no indentation. Unless..of course we did

.....int *p = null;

.........if (error) goto exit;
.........if (error) goto exit;
.........if (error) goto exit;

.....exit: