On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
> I included try-blocks and throw with a local jump.

Some samples:

try {
/*maybe inside nested loops*/
/*this is just a goto to the end of try block*/
throw;
} /*end of try block*/

try {
/*this is just a goto to inside catch block
throw; ​
} catch {
/*inside catch block*/
}

/*creates a variable 'int er' as defined in catch*/
try {
throw 1; /*sets the variable to 1 then jump*/
} catch (int er) {
/*inside catch block*/
}

try {
int i = 0;
try (i == 0);

/*same as if (!(i == 0)) throw;*/
}

try {
int i = 0;
try (i == 0) throw 2;

/*same as if (!(i == 0)) throw 2;*/
} catch (int er) {
}

try {
/*
Resource acquisition is initialization (RAII).
f checks the initialization
fclose is the dtor that is called at the end of scope
*/
try (FILE* f = fopen("t.txt", "r"); f; fclose(f)) throw errno;
} catch (int er) {
}

On Tuesday, 27 April 2021 at 23:45:01 UTC+3, Thiago Adams wrote:
> On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
> > I included try-blocks and throw with a local jump.
> Some samples:

Main use-case of exception usage is propagating information about
show-stopper issue down the calling stack without special code
needed in mid way functions.

For example we have function main() that asks file name from user and then
tries to call parse_file() that calls parse_list() that calls parse_record()
that calls parse_property() that throws exception about issue of parsing
the property. Then the exception breaks execution of all those
functions, is caught in main that then says to user that the supplied file
can't be parsed because it contains such issue.

So you seem to use syntax of feature that is good for something
with limitations that make it not useful for what the original is
good for. If so then that confuses initially and then disappoints,
no much fans won.

On Wednesday, April 28, 2021 at 1:20:06 AM UTC-3, Öö Tiib wrote:
> On Tuesday, 27 April 2021 at 23:45:01 UTC+3, Thiago Adams wrote:
> > On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
> > > I included try-blocks and throw with a local jump.
> > Some samples:
> Main use-case of exception usage is propagating information about
> show-stopper issue down the calling stack without special code
> needed in mid way functions.

I think a full error propagation can be done with out-arguments and a simple
propagation returning ints.

> For example we have function main() that asks file name from user and then
> tries to call parse_file() that calls parse_list() that calls parse_record()
> that calls parse_property() that throws exception about issue of parsing
> the property. Then the exception breaks execution of all those
> functions, is caught in main that then says to user that the supplied file
> can't be parsed because it contains such issue.

In this sample, I would write just.

struct parse_error {
int code;
/*message line col etc*/
};

int parse_record(struct parse_error* error) {

if ( /some error*/)
seterror(error, "Error parsing at..");

return error->code;
}

int parse_file(const char* file, struct parse_error* error) {
parse_list(error);
return error->code;
}

int main(int argc, char *argv[]) {
struct parse_error error = {0};
parse_file(argv[0], &error);
if (error->code) {
/*print error*/
}
}

I haven't used any "try " feature. This was on purpose
to show that things start to become useful after 2
try items.

For instance:

int parse_file(const char* file, struct parse_error* error) {

try {
try(parse_list(error) == 0) ;
try(parse_list2(error) == 0) ;
try(parse_list3(error) == 0) ;
try(parse_list4(error) == 0) ;
}
return error->code;
}

Note that I don't need to change the main function.

The "defer" (not used in this sample) also become interesting in
to UNDO some resource that was acquired and after error should be
discarded.

Note that our parse_file function has on its signature
the type of error it propagates. The type is checked at
compile time. (Comparing with C++ exceptions
if you throw a new type the caller does not need to change and
this can be dangerous)
How the error is propagated is not specified and different and
existing errors can be mixed.

> So you seem to use syntax of feature that is good for something
> with limitations that make it not useful for what the original is
> good for. If so then that confuses initially and then disappoints,
> no much fans won.

Yes...it is confuse but I guess still the best option because
at least try catch is know pattern.

When I am coding I compare the current implementation (in C)
with this alternative.

In the past I did some code like this:

parse_list(error);
parse_list2(error) ;
parse_list3(error);
parse_list4(error) ;

where I added in each parse function a check
int parse_()
{ if (error->code != 0) return error->code;
....
} then I did not add "ifs" and I let the "zig zag"
flow.

On Wednesday, 28 April 2021 at 14:39:01 UTC+3, Thiago Adams wrote:
> On Wednesday, April 28, 2021 at 1:20:06 AM UTC-3, Öö Tiib wrote:
> > On Tuesday, 27 April 2021 at 23:45:01 UTC+3, Thiago Adams wrote:
> > > On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
> > > > I included try-blocks and throw with a local jump.
> > > Some samples:
> > Main use-case of exception usage is propagating information about
> > show-stopper issue down the calling stack without special code
> > needed in mid way functions.
> I think a full error propagation can be done with out-arguments and a simple
> propagation returning ints.

Error handling can and often is done with explicit handling of out arguments
and/or return values. But the whole point of exceptions is to move that
exceptional code from algorithm code to error handling blocks.
Otherwise if functions called can fail we can't write readable algorithms like:

acceleration = velocity(object, end_time) - velocity(object. start_time)
/ (end_time - start_time) ;

We have to check if call to velocity failed right after call and that can't be
done in middle of expression.

The C++ proposal of static exceptions to what you gave link else thread is
alternative to current table-based stack unwinding, but is not changing
syntax of exceptions usage. It is performance-wise better fit for real time
systems and the point of mixing exceptions (with rarely occurring problems)
and manual error processing (with frequently occurring problems) is also
gone. Great proposal, but it is really more about ABI (under control of
monsters) and compiler (also under control of monsters) so it won't ever
happen.

It just does it internally differently than current ... roughly like that:
* The return value of noexcept(false) functions is turned into kind of tagged
union between return value type (if any) and all potentially thrown exception
information types behind scenes, programmer does need to type nothing
for that.
* The noexcept(true) functions call terminate() instead of returning exception
information.
* Caller of noexcept(false) functions checks return value of each call if it is
exception behind scenes.
* * On case it is not it runs on.
* * On case it is exception and code is not in try block it returns exception
information.
* * On case it is exception and code is in try block it searches for matching
catch first to last.
* * * If catch found then it jumps into that catch, catch(...) matches everything.
* * * If none of the catches match then return exception information.
* same logic is for explicit throw with argument.
* throw; without argument rethrows last exception.
* etc more of such details

> > For example we have function main() that asks file name from user and then
> > tries to call parse_file() that calls parse_list() that calls parse_record()
> > that calls parse_property() that throws exception about issue of parsing
> > the property. Then the exception breaks execution of all those
> > functions, is caught in main that then says to user that the supplied file
> > can't be parsed because it contains such issue.

Yes that misses whole point; idea of programming language features is to
make code more coherent, expressive and better structured not to add more
need of bloat to type or ways to type same bloat more verbosely.
Exceptions are such feature that has been here for decades and so people
expect something of those, bait-and-switch with those won't work.

> > So you seem to use syntax of feature that is good for something
> > with limitations that make it not useful for what the original is
> > good for. If so then that confuses initially and then disappoints,
> > no much fans won.
> Yes...it is confuse but I guess still the best option because
> at least try catch is know pattern.

It is, that's why I say that your "try" promises something, then confuses
"wtf is that" and finally disappoints "oh its not there, useless". Good
way to align market against you.

If you have windows box somewhere then download ms compiler
and turn on SEH exceptions in it.
<https://docs.microsoft.com/en-us/cpp/cpp/structured-exception-handling-c-cpp?view=msvc-160>
These are not that fun in C as C does not have RAII but at least useful
for having exception support in language so these do not disappoint
that badly. Making anything less convenient than those won't fly.
Combining with some trick to add RAII to C would likely feel great.

On Tuesday, April 27, 2021 at 5:45:01 PM UTC-3, Thiago Adams wrote:
> On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
> > I included try-blocks and throw with a local jump.
> Some samples:
....
> try {
> /*this is just a goto to inside catch block
> throw; ​
> }
> catch {
> /*inside catch block*/
> }

Emulation of this particular case with macros.

#define try int _try_block_error = 0; do
#define catch while(0); catch_label:; if (_try_block_error)
#define throw do { _try_block_error = 1; goto catch_label; } while (0)

int main() {

try
{
for (int i = 0; i < 10; i++)
{
for (int j = 0; j < 10; j++)
{
if (j == 1 && i == 5)
throw;
}
}
printf("continue..\n");
}
catch {
printf("catch\n");
}

}

On Friday, April 30, 2021 at 12:02:39 AM UTC-3, Thiago Adams wrote:
....
> Emulation of this particular case with macros.
>
>
> #define try int _try_block_error = 0; do
> #define catch while(0); catch_label:; if (_try_block_error)
> #define throw do { _try_block_error = 1; goto catch_label; } while (0)
>
[...]

I didn't know that we could use goto labels between else and { } !
and the code execution continues inside the else.

So, this is the alternative emulation.

#include <stdio.h>

#define try if (1)
#define catch else catch_label:
#define throw do { goto catch_label; } while (0)

int main()
{

try
{
throw;
}
catch
{
printf("catch\n");
}
printf("continue\n");

}

On 2021-04-30, Thiago Adams <thiago.adams@gmail.com> wrote:
> On Tuesday, April 27, 2021 at 5:45:01 PM UTC-3, Thiago Adams wrote:
>> On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
>> > I included try-blocks and throw with a local jump.
>> Some samples:
> ...
>> try {
>> /*this is just a goto to inside catch block
>> throw; ​
>> }
>> catch {
>> /*inside catch block*/
>> }
>
> Emulation of this particular case with macros.
>
>
> #define try int _try_block_error = 0; do
> #define catch while(0); catch_label:; if (_try_block_error)
> #define throw do { _try_block_error = 1; goto catch_label; } while (0)
>
>
> int main() {
>
> try
> {
> for (int i = 0; i < 10; i++)
> {
> for (int j = 0; j < 10; j++)
> {
> if (j == 1 && i == 5)
> throw;
> }
> }
> printf("continue..\n");
> }
> catch {
> printf("catch\n");
> }
>
> }

Without the following support, through any number of nestings, it's
pretty silly:

try
{
unwind_protect
{
for (int i = 0; i < 10; i++)
{
for (int j = 0; j < 10; j++)
{
if (j == 1 && i == 5)
throw;
}
}
printf("continue..\n"); // not printed
}
cleanup
{
printf("cleanup\n"); // printed
}
}
catch
{
printf("catch\n");
}

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Kaz Kylheku wrote:
> On 2021-04-30, Thiago Adams <thiago.adams@gmail.com> wrote:
>> On Tuesday, April 27, 2021 at 5:45:01 PM UTC-3, Thiago Adams wrote:
>>> On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
>>>> I included try-blocks and throw with a local jump.
>>> Some samples:
>> ...
>>> try {
>>> /*this is just a goto to inside catch block
>>> throw; ​
>>> }
>>> catch {
>>> /*inside catch block*/
>>> }
>>
>> Emulation of this particular case with macros.
>>
>>
>> #define try int _try_block_error = 0; do
>> #define catch while(0); catch_label:; if (_try_block_error)
>> #define throw do { _try_block_error = 1; goto catch_label; } while (0)
>>
>>
>> int main() {
>>
>> try
>> {
>> for (int i = 0; i < 10; i++)
>> {
>> for (int j = 0; j < 10; j++)
>> {
>> if (j == 1 && i == 5)
>> throw;
>> }
>> }
>> printf("continue..\n");
>> }
>> catch {
>> printf("catch\n");
>> }
>>
>> }
>
> Without the following support, through any number of nestings, it's
> pretty silly:
>
> try
> {
> unwind_protect
> {
> for (int i = 0; i < 10; i++)
> {
> for (int j = 0; j < 10; j++)
> {
> if (j == 1 && i == 5)
> throw;
> }
> }
> printf("continue..\n"); // not printed
> }
> cleanup
> {
> printf("cleanup\n"); // printed
> }
> }
> catch
> {
> printf("catch\n");
> }
>
>

I started to use these macros in a real project doing the changes
necessary and I pretty happy!

When I was doing the changes I realize in most cases I would prefer
to use a "if" instead of just automatic throw.

For instance, I propose this syntax

try {
try (FILE* f = fopen("input.txt", "r"); f; fclose(f)) throw errno;
} catch(int error) {}

But for real code it was better a "if" to create better error messages
with the context of the caller.

(
If you throw something deep inside using C++ exceptions for instance,
the changes the error message is inappropriate are big.
)

/*stores code and message*/

struct error error = {0};

FILE* f = 0; /*outsize*/

try {
f = fopen("config.txt", "r");
if (f == NULL){
seterror(&error, "cannot open config file");
throw;
}

}
catch {
printf("%s %d\n", error->message, error->code);
}

/*check and clear*/
if (f != NULL) {
fclose(f);
}

With this pattern the resources are declared outside try-block,
initialized inside and cleared outsize using a test (generally != NULL)

I don't like "returns" in the middle of my C code, but I am pretty
comfortable with this throw pattern.

Another sample.

#include <stdio.h>

#define try if (1)
#define catch else catch_label:
#define throw do { goto catch_label; } while (0)

struct Person {
char* name;
char* address;
};

void DeletePerson(struct Person* p) {
if (p)
{
free(p->name);
free(p->address);
free(p);
}
}

struct Person* CreatePerson(char* name, char * address)
{ struct Person* p = 0;
try
{
p = calloc(1, sizeof * p);
if (p == NULL) throw;
p->name = _strdup(name);
p->address = _strdup(address);
if (p->name == NULL || p->address == NULL)
{
throw;
}
}
catch
{
DeletePerson(p);
p = 0;
}
return p;
}

int main() {

struct Person* person = 0;
try
{
person = CreatePerson("name", "address");
if (person == NULL)
{
printf("out of mem\n");
throw;
}
printf("%s %s\n", person->name, person->address);
}
catch
{
}
DeletePerson(person);
}

Compare other alternatives for "CreatePerson" and you will
see that this alternative is clear.

By the way, something that simplifies code is to create a
malloc that is "alloc or die" and just ignore the result,
but I am don't fell comfortable in exit a server for instance.

Thiago Adams <thiago.adams@gmail.com> writes:

> Kaz Kylheku wrote:
>> On 2021-04-30, Thiago Adams <thiago.adams@gmail.com> wrote:
>>> On Tuesday, April 27, 2021 at 5:45:01 PM UTC-3, Thiago Adams wrote:
>>>> On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
>>>>> I included try-blocks and throw with a local jump.
>>>> Some samples:
>>> ...
>>>> try {
>>>> /*this is just a goto to inside catch block
>>>> throw; ​
>>>> }
>>>> catch {
>>>> /*inside catch block*/
>>>> }
>>>
>>> Emulation of this particular case with macros.
>>>
>>>
>>> #define try int _try_block_error = 0; do
>>> #define catch while(0); catch_label:; if (_try_block_error)
>>> #define throw do { _try_block_error = 1; goto catch_label; } while (0)
>>>
>>>
>>> int main() {
>>> try
>>> {
>>> for (int i = 0; i < 10; i++)
>>> {
>>> for (int j = 0; j < 10; j++)
>>> {
>>> if (j == 1 && i == 5)
>>> throw;
>>> }
>>> }
>>> printf("continue..\n");
>>> }
>>> catch {
>>> printf("catch\n");
>>> }
>>>
>>> }
>>
>> Without the following support, through any number of nestings, it's
>> pretty silly:
>>
>> try
>> {
>> unwind_protect
>> {
>> for (int i = 0; i < 10; i++)
>> {
>> for (int j = 0; j < 10; j++)
>> {
>> if (j == 1 && i == 5)
>> throw;
>> }
>> }
>> printf("continue..\n"); // not printed
>> }
>> cleanup
>> {
>> printf("cleanup\n"); // printed
>> }
>> }
>> catch
>> {
>> printf("catch\n");
>> }

This seems like an important point.

> I started to use these macros in a real project doing the changes
> necessary and I pretty happy!

How is it better than just leaving the label and the goto obvious for
all to see?

> Another sample.
>
> #include <stdio.h>
>
> #define try if (1)
> #define catch else catch_label:
> #define throw do { goto catch_label; } while (0)
>
> struct Person {
> char* name;
> char* address;
> };
>
> void DeletePerson(struct Person* p) {
> if (p)
> {
> free(p->name);
> free(p->address);
> free(p);
> }
> }
>
> struct Person* CreatePerson(char* name, char * address)
> {
> struct Person* p = 0;
> try
> {
> p = calloc(1, sizeof * p);
> if (p == NULL) throw;
> p->name = _strdup(name);
> p->address = _strdup(address);
> if (p->name == NULL || p->address == NULL)
> {
> throw;
> }
> }
> catch
> {
> DeletePerson(p);
> p = 0;
> }
> return p;
> }

struct Person *CreatePerson(char *name, char *address)
{
struct Person *p = calloc(1, sizeof *p);
if (p && (p->name = strdup(name)) && (p->address = strdup(address)))
return p;
DeletePerson(p);
return 0;
}

> Compare other alternatives for "CreatePerson" and you will
> see that this alternative is clear.

I can't check yours without looking at a bunch of macros. I thought
we'd left all that behind in the 1980s.

--
Ben.

On Friday, April 30, 2021 at 12:54:33 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes:
>
> > Kaz Kylheku wrote:
> >> On 2021-04-30, Thiago Adams <thiago...@gmail.com> wrote:
> >>> On Tuesday, April 27, 2021 at 5:45:01 PM UTC-3, Thiago Adams wrote:
> >>>> On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
> >>>>> I included try-blocks and throw with a local jump.
> >>>> Some samples:
> >>> ...
> >>>> try {
> >>>> /*this is just a goto to inside catch block
> >>>> throw; ​
> >>>> }
> >>>> catch {
> >>>> /*inside catch block*/
> >>>> }
> >>>
> >>> Emulation of this particular case with macros.
> >>>
> >>>
> >>> #define try int _try_block_error = 0; do
> >>> #define catch while(0); catch_label:; if (_try_block_error)
> >>> #define throw do { _try_block_error = 1; goto catch_label; } while (0)
> >>>
> >>>
> >>> int main() {
> >>> try
> >>> {
> >>> for (int i = 0; i < 10; i++)
> >>> {
> >>> for (int j = 0; j < 10; j++)
> >>> {
> >>> if (j == 1 && i == 5)
> >>> throw;
> >>> }
> >>> }
> >>> printf("continue..\n");
> >>> }
> >>> catch {
> >>> printf("catch\n");
> >>> }
> >>>
> >>> }
> >>
> >> Without the following support, through any number of nestings, it's
> >> pretty silly:
> >>
> >> try
> >> {
> >> unwind_protect
> >> {
> >> for (int i = 0; i < 10; i++)
> >> {
> >> for (int j = 0; j < 10; j++)
> >> {
> >> if (j == 1 && i == 5)
> >> throw;
> >> }
> >> }
> >> printf("continue..\n"); // not printed
> >> }
> >> cleanup
> >> {
> >> printf("cleanup\n"); // printed
> >> }
> >> }
> >> catch
> >> {
> >> printf("catch\n");
> >> }
> This seems like an important point.
> > I started to use these macros in a real project doing the changes
> > necessary and I pretty happy!
> How is it better than just leaving the label and the goto obvious for
> all to see?

goto errorlabel;

errorlabel:

> > Another sample.
> >
> > #include <stdio.h>
> >
> > #define try if (1)
> > #define catch else catch_label:
> > #define throw do { goto catch_label; } while (0)
> >
> > struct Person {
> > char* name;
> > char* address;
> > };
> >
> > void DeletePerson(struct Person* p) {
> > if (p)
> > {
> > free(p->name);
> > free(p->address);
> > free(p);
> > }
> > }
> >
> > struct Person* CreatePerson(char* name, char * address)
> > {
> > struct Person* p = 0;
> > try
> > {
> > p = calloc(1, sizeof * p);
> > if (p == NULL) throw;
> > p->name = _strdup(name);
> > p->address = _strdup(address);
> > if (p->name == NULL || p->address == NULL)
> > {
> > throw;
> > }
> > }
> > catch
> > {
> > DeletePerson(p);
> > p = 0;
> > }
> > return p;
> > }
>
> struct Person *CreatePerson(char *name, char *address)
> {
> struct Person *p = calloc(1, sizeof *p);
> if (p && (p->name = strdup(name)) && (p->address = strdup(address)))
> return p;
> DeletePerson(p);
> return 0;
> }

I liked this solution for this specific function.

But I could not apply the same idea on the code I am using these
macros. I my code I am setting an error message for each step
not completed.

For instance:

try
{ if (Step1() != 0)
{
seterror(error, "could not complete step 1 because...");
throw;
}

if (Step2() != 0)
{
seterror(error, "could not complete step 2 because...");
throw;
}
DoSomethingOnSuccess();
} catch
{ DoSomethingOnError();
}

DoSomethingAlways();

--x--
Alternative 1 -
call DoSomethingAlways(); in two places.

if (Step1() != 0)
{
seterror(error, "could not complete step 1 because...");
goto error_label;
}

if (Step2() != 0)
{
seterror(error, "could not complete step 2 because...");
goto error_label;
}
DoSomethingOnSuccess();
DoSomethingAlways();
return;

error_label:
DoSomethingOnError();
DoSomethingAlways();
return;

--x--

Alternative 2

if (Step1() != 0)
{
seterror(error, "could not complete step 1 because...");
goto error_label;
}

if (Step2() != 0)
{
seterror(error, "could not complete step 2 because...");
goto error_label;
}

DoSomethingOnSuccess();

error_label:

if (errorvariable_set)
DoSomethingOnError();

DoSomethingAlways();
return;

Any ideas for this?

Thiago Adams <thiago.adams@gmail.com> writes:

> On Friday, April 30, 2021 at 12:54:33 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>
>> > Kaz Kylheku wrote:
>> >> On 2021-04-30, Thiago Adams <thiago...@gmail.com> wrote:
>> >>> On Tuesday, April 27, 2021 at 5:45:01 PM UTC-3, Thiago Adams wrote:
>> >>>> On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
>> >>>>> I included try-blocks and throw with a local jump.
>> >>>> Some samples:
>> >>> ...
>> >>>> try {
>> >>>> /*this is just a goto to inside catch block
>> >>>> throw; ​
>> >>>> }
>> >>>> catch {
>> >>>> /*inside catch block*/
>> >>>> }
>> >>>
>> >>> Emulation of this particular case with macros.
>> >>>
>> >>>
>> >>> #define try int _try_block_error = 0; do
>> >>> #define catch while(0); catch_label:; if (_try_block_error)
>> >>> #define throw do { _try_block_error = 1; goto catch_label; } while (0)
>> >>>
>> >>>
>> >>> int main() {
>> >>> try
>> >>> {
>> >>> for (int i = 0; i < 10; i++)
>> >>> {
>> >>> for (int j = 0; j < 10; j++)
>> >>> {
>> >>> if (j == 1 && i == 5)
>> >>> throw;
>> >>> }
>> >>> }
>> >>> printf("continue..\n");
>> >>> }
>> >>> catch {
>> >>> printf("catch\n");
>> >>> }
>> >>>
>> >>> }
>> >>
>> >> Without the following support, through any number of nestings, it's
>> >> pretty silly:
>> >>
>> >> try
>> >> {
>> >> unwind_protect
>> >> {
>> >> for (int i = 0; i < 10; i++)
>> >> {
>> >> for (int j = 0; j < 10; j++)
>> >> {
>> >> if (j == 1 && i == 5)
>> >> throw;
>> >> }
>> >> }
>> >> printf("continue..\n"); // not printed
>> >> }
>> >> cleanup
>> >> {
>> >> printf("cleanup\n"); // printed
>> >> }
>> >> }
>> >> catch
>> >> {
>> >> printf("catch\n");
>> >> }
>> This seems like an important point.
>> > I started to use these macros in a real project doing the changes
>> > necessary and I pretty happy!
>> How is it better than just leaving the label and the goto obvious for
>> all to see?
>
> goto errorlabel;
>
> errorlabel:

I was not very clear. I wanted to know why you think hiding the label
and the goto inside macros helps. Any hiding of what's happening has to
be worth the cost in clarity.

>> > Another sample.
>> >
>> > #include <stdio.h>
>> >
>> > #define try if (1)
>> > #define catch else catch_label:
>> > #define throw do { goto catch_label; } while (0)
>> >
>> > struct Person {
>> > char* name;
>> > char* address;
>> > };
>> >
>> > void DeletePerson(struct Person* p) {
>> > if (p)
>> > {
>> > free(p->name);
>> > free(p->address);
>> > free(p);
>> > }
>> > }
>> >
>> > struct Person* CreatePerson(char* name, char * address)
>> > {
>> > struct Person* p = 0;
>> > try
>> > {
>> > p = calloc(1, sizeof * p);
>> > if (p == NULL) throw;
>> > p->name = _strdup(name);
>> > p->address = _strdup(address);
>> > if (p->name == NULL || p->address == NULL)
>> > {
>> > throw;
>> > }
>> > }
>> > catch
>> > {
>> > DeletePerson(p);
>> > p = 0;
>> > }
>> > return p;
>> > }
>>
>> struct Person *CreatePerson(char *name, char *address)
>> {
>> struct Person *p = calloc(1, sizeof *p);
>> if (p && (p->name = strdup(name)) && (p->address = strdup(address)))
>> return p;
>> DeletePerson(p);
>> return 0;
>> }
>
> I liked this solution for this specific function.
>
> But I could not apply the same idea on the code I am using these
> macros. I my code I am setting an error message for each step
> not completed.
>
> For instance:
>
> try
> {
> if (Step1() != 0)
> {
> seterror(error, "could not complete step 1 because...");
> throw;
> }
>
> if (Step2() != 0)
> {
> seterror(error, "could not complete step 2 because...");
> throw;
> }
> DoSomethingOnSuccess();
> }
> catch
> {
> DoSomethingOnError();
> }
>
> DoSomethingAlways();

if (Step1() != 0) {
seterror(error, "could not complete step 1 because...");
DoSomethingOnError();
}
else if (Step2() != 0) {
seterror(error, "could not complete step 2 because...");
DoSomethingOnError();
}
else DoSomethingOnSuccess();

DoSomethingAlways();

I can't see how it could be clearer than this, but maybe I have
old-fashioned views about coding.

> Any ideas for this?

I suspect this is not really what your use-case looks like, but I can
only re-write code that is shown.

--
Ben.

On Friday, April 30, 2021 at 5:45:32 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes:
>
> > On Friday, April 30, 2021 at 12:54:33 PM UTC-3, Ben Bacarisse wrote:
> >> Thiago Adams <thiago...@gmail.com> writes:
> >>
> >> > Kaz Kylheku wrote:
> >> >> On 2021-04-30, Thiago Adams <thiago...@gmail.com> wrote:
> >> >>> On Tuesday, April 27, 2021 at 5:45:01 PM UTC-3, Thiago Adams wrote:
> >> >>>> On Thursday, April 22, 2021 at 6:16:55 PM UTC-3, Thiago Adams wrote:
> >> >>>>> I included try-blocks and throw with a local jump.
> >> >>>> Some samples:
> >> >>> ...
> >> >>>> try {
> >> >>>> /*this is just a goto to inside catch block
> >> >>>> throw; ​
> >> >>>> }
> >> >>>> catch {
> >> >>>> /*inside catch block*/
> >> >>>> }
> >> >>>
> >> >>> Emulation of this particular case with macros.
> >> >>>
> >> >>>
> >> >>> #define try int _try_block_error = 0; do
> >> >>> #define catch while(0); catch_label:; if (_try_block_error)
> >> >>> #define throw do { _try_block_error = 1; goto catch_label; } while (0)
> >> >>>
> >> >>>
> >> >>> int main() {
> >> >>> try
> >> >>> {
> >> >>> for (int i = 0; i < 10; i++)
> >> >>> {
> >> >>> for (int j = 0; j < 10; j++)
> >> >>> {
> >> >>> if (j == 1 && i == 5)
> >> >>> throw;
> >> >>> }
> >> >>> }
> >> >>> printf("continue..\n");
> >> >>> }
> >> >>> catch {
> >> >>> printf("catch\n");
> >> >>> }
> >> >>>
> >> >>> }
> >> >>
> >> >> Without the following support, through any number of nestings, it's
> >> >> pretty silly:
> >> >>
> >> >> try
> >> >> {
> >> >> unwind_protect
> >> >> {
> >> >> for (int i = 0; i < 10; i++)
> >> >> {
> >> >> for (int j = 0; j < 10; j++)
> >> >> {
> >> >> if (j == 1 && i == 5)
> >> >> throw;
> >> >> }
> >> >> }
> >> >> printf("continue..\n"); // not printed
> >> >> }
> >> >> cleanup
> >> >> {
> >> >> printf("cleanup\n"); // printed
> >> >> }
> >> >> }
> >> >> catch
> >> >> {
> >> >> printf("catch\n");
> >> >> }
> >> This seems like an important point.
> >> > I started to use these macros in a real project doing the changes
> >> > necessary and I pretty happy!
> >> How is it better than just leaving the label and the goto obvious for
> >> all to see?
> >
> > goto errorlabel;
> >
> > errorlabel:
> I was not very clear. I wanted to know why you think hiding the label
> and the goto inside macros helps. Any hiding of what's happening has to
> be worth the cost in clarity.

Yes, generally I don't use macros to change the meaning of the language.
But in this case I am happy with it!

> >> > Another sample.
> >> >
> >> > #include <stdio.h>
> >> >
> >> > #define try if (1)
> >> > #define catch else catch_label:
> >> > #define throw do { goto catch_label; } while (0)
> >> >
> >> > struct Person {
> >> > char* name;
> >> > char* address;
> >> > };
> >> >
> >> > void DeletePerson(struct Person* p) {
> >> > if (p)
> >> > {
> >> > free(p->name);
> >> > free(p->address);
> >> > free(p);
> >> > }
> >> > }
> >> >
> >> > struct Person* CreatePerson(char* name, char * address)
> >> > {
> >> > struct Person* p = 0;
> >> > try
> >> > {
> >> > p = calloc(1, sizeof * p);
> >> > if (p == NULL) throw;
> >> > p->name = _strdup(name);
> >> > p->address = _strdup(address);
> >> > if (p->name == NULL || p->address == NULL)
> >> > {
> >> > throw;
> >> > }
> >> > }
> >> > catch
> >> > {
> >> > DeletePerson(p);
> >> > p = 0;
> >> > }
> >> > return p;
> >> > }
> >>
> >> struct Person *CreatePerson(char *name, char *address)
> >> {
> >> struct Person *p = calloc(1, sizeof *p);
> >> if (p && (p->name = strdup(name)) && (p->address = strdup(address)))
> >> return p;
> >> DeletePerson(p);
> >> return 0;
> >> }
> >
> > I liked this solution for this specific function.
> >
> > But I could not apply the same idea on the code I am using these
> > macros. I my code I am setting an error message for each step
> > not completed.
> >
> > For instance:
> >
> > try
> > {
> > if (Step1() != 0)
> > {
> > seterror(error, "could not complete step 1 because...");
> > throw;
> > }
> >
> > if (Step2() != 0)
> > {
> > seterror(error, "could not complete step 2 because...");
> > throw;
> > }
> > DoSomethingOnSuccess();
> > }
> > catch
> > {
> > DoSomethingOnError();
> > }
> >
> > DoSomethingAlways();
>
> if (Step1() != 0) {
> seterror(error, "could not complete step 1 because...");
> DoSomethingOnError();
> }
> else if (Step2() != 0) {
> seterror(error, "could not complete step 2 because...");
> DoSomethingOnError();
> }
> else DoSomethingOnSuccess();
>
> DoSomethingAlways();
>
> I can't see how it could be clearer than this, but maybe I have
> old-fashioned views about coding.
>
> > Any ideas for this?
>
> I suspect this is not really what your use-case looks like, but I can
> only re-write code that is shown.

I also think this solution :

if (Step1() == error) { OnError(); }
else if (Step2() == error) { OnError(); }
else { OnSuccess(); }

is good because it also looks sequential steps.

But there is some differences in the code I am using
(sorry for not posting the real code but it is not public source)
because I have other variables and steps in between and this
would created nested ifs moving the success to inside adding
a sequence of }}} at the end.

For instance:

if (Step1() == error) {
OnError();
}
else {
int index = Find();
if (index = -1) {
OnError();
}
else {
if (Step2(index) == error) {
OnError();
}
else if (Step3() == error) {
OnError();
}
else {
OnSuccess();
}
}
}

--x--

Here is a version that is more similar of what I am using
and where I am happy with these macros.

void F()
{ try
{
char var1[100];
if (Step1(var1) != 0)
{
seterror("cannot complete step1 because..");
throw;
}

char var2[100];
if (Step2(var2) != 0)
{
seterror("cannot complete step2 because..");
throw;
}

int index = Step3();
if (index == -1)
{
seterror("invalid result..");
throw;
}

if (Step4(index) != 0)
{
seterror("cannot complete step4 because..");
throw;
}

DoOnSuccess();
}
catch
{
DoOnError();
}
DoAlways();
}

Thiago Adams <thiago.adams@gmail.com> writes:

> I also think this solution :
>
> if (Step1() == error) { OnError(); }
> else if (Step2() == error) { OnError(); }
> else { OnSuccess(); }
>
> is good because it also looks sequential steps.
>
> But there is some differences in the code I am using

This sort of thread always turns out like this.

> (sorry for not posting the real code but it is not public source)
> because I have other variables and steps in between and this
> would created nested ifs moving the success to inside adding
> a sequence of }}} at the end.

Without equivalent code that I and other can asses, your statements
can't be challenged.

> For instance:
>
> if (Step1() == error) {
> OnError();
> }
> else {
> int index = Find();
> if (index = -1) {
> OnError();
> }
> else {
> if (Step2(index) == error) {
> OnError();
> }
> else if (Step3() == error) {
> OnError();
> }
> else {
> OnSuccess();
> }
> }
> }

I would not write that, but I don't think it's worth showing an
alternative version. Whatever I write, the real code will be different
and will absolutely not be clear written in my preferred style.

> --x--
>
> Here is a version that is more similar of what I am using
> and where I am happy with these macros.

Are the people who will come along and read your code as happy with them
as you are?

> void F()
> {
> try
> {
> char var1[100];
> if (Step1(var1) != 0)
> {
> seterror("cannot complete step1 because..");
> throw;
> }
>
> char var2[100];
> if (Step2(var2) != 0)
> {
> seterror("cannot complete step2 because..");
> throw;
> }
>
> int index = Step3();
> if (index == -1)
> {
> seterror("invalid result..");
> throw;
> }
>
> if (Step4(index) != 0)
> {
> seterror("cannot complete step4 because..");
> throw;
> }
>
> DoOnSuccess();
> }
> catch
> {
> DoOnError();
> }
> DoAlways();
> }

I would re-write this exactly as I did the other example. The locality
of declaration is not worth the ensuing mess.

You may get the impression that I am a little cross. I am, but I am
cross with myself. I knew how this would end before my first post. You
are happy, and I should really have just left it at that.

--
Ben.

On Saturday, May 1, 2021 at 5:29:42 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes:
>
> > I also think this solution :
> >
> > if (Step1() == error) { OnError(); }
> > else if (Step2() == error) { OnError(); }
> > else { OnSuccess(); }
> >
> > is good because it also looks sequential steps.
> >
> > But there is some differences in the code I am using
> This sort of thread always turns out like this.
> > (sorry for not posting the real code but it is not public source)
> > because I have other variables and steps in between and this
> > would created nested ifs moving the success to inside adding
> > a sequence of }}} at the end.
> Without equivalent code that I and other can asses, your statements
> can't be challenged.
> > For instance:
> >
> > if (Step1() == error) {
> > OnError();
> > }
> > else {
> > int index = Find();
> > if (index = -1) {
> > OnError();
> > }
> > else {
> > if (Step2(index) == error) {
> > OnError();
> > }
> > else if (Step3() == error) {
> > OnError();
> > }
> > else {
> > OnSuccess();
> > }
> > }
> > }
> I would not write that, but I don't think it's worth showing an
> alternative version. Whatever I write, the real code will be different
> and will absolutely not be clear written in my preferred style.
> > --x--
> >
> > Here is a version that is more similar of what I am using
> > and where I am happy with these macros.
> Are the people who will come along and read your code as happy with them
> as you are?
> > void F()
> > {
> > try
> > {
> > char var1[100];
> > if (Step1(var1) != 0)
> > {
> > seterror("cannot complete step1 because..");
> > throw;
> > }
> >
> > char var2[100];
> > if (Step2(var2) != 0)
> > {
> > seterror("cannot complete step2 because..");
> > throw;
> > }
> >
> > int index = Step3();
> > if (index == -1)
> > {
> > seterror("invalid result..");
> > throw;
> > }
> >
> > if (Step4(index) != 0)
> > {
> > seterror("cannot complete step4 because..");
> > throw;
> > }
> >
> > DoOnSuccess();
> > }
> > catch
> > {
> > DoOnError();
> > }
> > DoAlways();
> > }
> I would re-write this exactly as I did the other example. The locality
> of declaration is not worth the ensuing mess.

I think the point is the insertion of other declarations and/or statements
between two steps that can fail and needed to be checked.
declarations can be moved.. but statements needs a logical order.

Step1()
/*declarations*/
/*other statements*/
Step2()

Without statements between..

if (Step1() == 0 &&
Step2() == 0) { /*success*/}
or

if (Step1() != 0) { /*error*/ }
else if(Step2() != 0) { /*error*/ }
else { /*success*/ }

Adding something between..

if (Step1() != 0) { goto error_label; }

/*some other statements, if for etc..*/

if(Step2() != 0) { goto error_label; }

/*success*/
return;

error_label:

return;

These try-catch-throw macros or normal goto jumps helps in the
situation where we have other statements in between avoiding nested ifs.

Compared with normal goto I think the macros helps with this last part where
it is confusing two returns.
> You may get the impression that I am a little cross. I am, but I am
> cross with myself. I knew how this would end before my first post. You
> are happy, and I should really have just left it at that.

What is interesting in C, we can have different styles and sometimes
we may be blind for using one style for many years.

On Sunday, May 2, 2021 at 8:43:14 AM UTC-3, Thiago Adams wrote:
....
> These try-catch-throw macros or normal goto jumps helps in the
> situation where we have other statements in between avoiding nested ifs.
>
> Compared with normal goto I think the macros helps with this last part where
> it is confusing two returns.

Just to show, how some people uses jumps for error handling in C, and maybe
use this as argument to include these try-blocks in C , here is a real code
from a open source library called opc ua ansi stack.

The usage pattern in this lib is this:

{
/*jumps to BeginErrorHandling in case of error*/
OpcUa_GotoErrorIfBad(code);

/*normal function return*/
OpcUa_ReturnStatusCode; /*return code;*/

/*error return*/
OpcUa_BeginErrorHandling; /*defines Error:*/
/*error handling*/
OpcUa_FinishErrorHandling; /*return code;*/
}

This pattern can be easy adapted to use these try catch blocks
and in my opinion it brings a lot of clarity keeping the same
design that motivate the usage of these macros.

--x--
In case someone wants to see a real code from this lib.

OpcUa_StatusCode OpcUa_P_OpenSSL_HMAC_SHA1_Verify(
OpcUa_CryptoProvider* a_pProvider,
OpcUa_Byte* a_pData,
OpcUa_UInt32 a_dataLen,
OpcUa_Key* a_key,
OpcUa_ByteString* a_pSignature)
{ OpcUa_ByteString mac = OPCUA_BYTESTRING_STATICINITIALIZER;

OpcUa_InitializeStatus(OpcUa_Module_P_OpenSSL, "HMAC_SHA1_Verify");

OpcUa_ReturnErrorIfArgumentNull(a_pSignature);
OpcUa_ReturnErrorIfArgumentNull(a_key);
OpcUa_ReturnErrorIfArgumentNull(a_key->Key.Data);

if(a_key->Key.Length < 1)
{
uStatus = OpcUa_BadInvalidArgument;
OpcUa_GotoErrorIfBad(uStatus);
}

if(a_pSignature->Length != 20)
{
uStatus = OpcUa_BadInvalidArgument;
OpcUa_GotoErrorIfBad(uStatus);
}

if((OpcUa_Int32)a_dataLen < 1)
{
uStatus = OpcUa_BadInvalidArgument;
OpcUa_GotoErrorIfBad(uStatus);
}

uStatus = OpcUa_P_OpenSSL_HMAC_SHA1_Generate(
a_pProvider,
a_pData,
a_dataLen,
a_key,
&mac);
OpcUa_GotoErrorIfBad(uStatus);

if(mac.Length > 0)
{
mac.Data = (OpcUa_Byte*)OpcUa_P_Memory_Alloc(mac.Length*sizeof(OpcUa_Byte));
OpcUa_GotoErrorIfAllocFailed(mac.Data);
}
else
{
uStatus = OpcUa_Bad;
OpcUa_GotoErrorIfBad(uStatus);
}

uStatus = OpcUa_P_OpenSSL_HMAC_SHA1_Generate(
a_pProvider,
a_pData,
a_dataLen,
a_key,
&mac);
OpcUa_GotoErrorIfBad(uStatus);

if((OpcUa_MemCmp(mac.Data, a_pSignature->Data, mac.Length))==0)
{
uStatus = OpcUa_Good;
}
else
{
uStatus = OpcUa_BadSignatureInvalid;
}

if(mac.Data != OpcUa_Null)
{
OpcUa_P_Memory_Free(mac.Data);
}

OpcUa_ReturnStatusCode;
OpcUa_BeginErrorHandling;

if(mac.Data != OpcUa_Null)
{
OpcUa_P_Memory_Free(mac.Data);
}

OpcUa_FinishErrorHandling;
}

Thiago Adams <thiago.adams@gmail.com> writes:

> On Saturday, May 1, 2021 at 5:29:42 PM UTC-3, Ben Bacarisse wrote:

>> Are the people who will come along and read your code as happy with them
>> as you are?

>> I would re-write this exactly as I did the other example. The locality
>> of declaration is not worth the ensuing mess.
>
> I think the point is the insertion of other declarations and/or statements
> between two steps that can fail and needed to be checked.

So even that was not the code that needed the macros. I thought it
wouldn't be.

> declarations can be moved.. but statements needs a logical order.

> Step1()
> /*declarations*/
> /*other statements*/
> Step2()
>
> Without statements between..
>
> if (Step1() == 0 &&
> Step2() == 0) { /*success*/}
> or
>
> if (Step1() != 0) { /*error*/ }
> else if(Step2() != 0) { /*error*/ }
> else { /*success*/ }
>
> Adding something between..
>
> if (Step1() != 0) { goto error_label; }
>
> /*some other statements, if for etc..*/
>
> if(Step2() != 0) { goto error_label; }
>
> /*success*/
> return;
>
> error_label:
>
> return;

But this is not the "killer" code pattern either, is it? Should I spend
a moment showing how I would write it? No, there will just be another
example that absolutely really is totally better written using the
mystery macros.

> These try-catch-throw macros or normal goto jumps helps in the
> situation where we have other statements in between avoiding nested
> ifs.

As I said:

>> Without equivalent code that I and other can asses, your statements
>> can't be challenged.

> Compared with normal goto I think the macros helps with this last part where
> it is confusing two returns.

>> Without equivalent code that I and other can asses, your statements
>> can't be challenged.

--
Ben.

On 02/05/2021 14:29, Ben Bacarisse wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> On Saturday, May 1, 2021 at 5:29:42 PM UTC-3, Ben Bacarisse wrote:
>
>>> Are the people who will come along and read your code as happy with them
>>> as you are?
>
>>> I would re-write this exactly as I did the other example. The locality
>>> of declaration is not worth the ensuing mess.
>>
>> I think the point is the insertion of other declarations and/or statements
>> between two steps that can fail and needed to be checked.
>
> So even that was not the code that needed the macros. I thought it
> wouldn't be.

I don't know what the capabilies are of the OP's proposal for C. But I'd
have thought the advantages of conventional try/catch are clear.

I rarely use exceptions and have only implemented them once (for
exceptions raised in user code). Using the same C-style syntax, they
might look like this:

try {
... any code ...
} catch (errorcode) {
... deal with error
}

The exception is thrown while executing the any-code block, but that
could be anywhere including deep inside a nested function:

if (some error detected) throw (errorcode);

So the advantage is that it can return directly from a nested function.
But also, that 'throw' statement could also be in inline code. Although
from the bits I've seen of the proposal, I think it needs a specific
errorcode (since this try-block might itself be executing unside another
try-block, or different errors could be thrown, needing catching
separately).

I don't know how practical this would be to emulate in C. (I did my
version for an interpreted language where stack-unwinding was easy to
do. However I remember having to prohibit gotos in and out of a
try-block as it would have screwed things up.)

Bart <bc@freeuk.com> writes:

> On 02/05/2021 14:29, Ben Bacarisse wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>
>>> On Saturday, May 1, 2021 at 5:29:42 PM UTC-3, Ben Bacarisse wrote:
>>
>>>> Are the people who will come along and read your code as happy with them
>>>> as you are?
>>
>>>> I would re-write this exactly as I did the other example. The locality
>>>> of declaration is not worth the ensuing mess.
>>>
>>> I think the point is the insertion of other declarations and/or statements
>>> between two steps that can fail and needed to be checked.
>>
>> So even that was not the code that needed the macros. I thought it
>> wouldn't be.
>
> I don't know what the capabilies are of the OP's proposal for C. But
> I'd have thought the advantages of conventional try/catch are clear.

I don't think it's wise, on Usenet, to assume that anything is clear.
Somethings will be clear to some people, but every topic will be a
complete mystery to many.

If you want to know what the OP is talking about, it's three macros
available up-thread.

--
Ben.

On Sunday, May 2, 2021 at 2:10:03 PM UTC-3, Bart wrote:
> On 02/05/2021 14:29, Ben Bacarisse wrote:
> > Thiago Adams <thiago...@gmail.com> writes:
> >
> >> On Saturday, May 1, 2021 at 5:29:42 PM UTC-3, Ben Bacarisse wrote:
> >
> >>> Are the people who will come along and read your code as happy with them
> >>> as you are?
> >
> >>> I would re-write this exactly as I did the other example. The locality
> >>> of declaration is not worth the ensuing mess.
> >>
> >> I think the point is the insertion of other declarations and/or statements
> >> between two steps that can fail and needed to be checked.
> >
> > So even that was not the code that needed the macros. I thought it
> > wouldn't be.
> I don't know what the capabilies are of the OP's proposal for C. But I'd
> have thought the advantages of conventional try/catch are clear.
>
> I rarely use exceptions and have only implemented them once (for
> exceptions raised in user code). Using the same C-style syntax, they
> might look like this:
>
> try {
> ... any code ...
> } catch (errorcode) {
> ... deal with error
> }
>
> The exception is thrown while executing the any-code block, but that
> could be anywhere including deep inside a nested function:
>
> if (some error detected) throw (errorcode);
>
> So the advantage is that it can return directly from a nested function.
> But also, that 'throw' statement could also be in inline code. Although
> from the bits I've seen of the proposal, I think it needs a specific
> errorcode (since this try-block might itself be executing unside another
> try-block, or different errors could be thrown, needing catching
> separately).
>
> I don't know how practical this would be to emulate in C. (I did my
> version for an interpreted language where stack-unwinding was easy to
> do. However I remember having to prohibit gotos in and out of a
> try-block as it would have screwed things up.)

The try-block I suggested is always local. throw must be inside the local
try block. No need for stack-unwinding.

I also suggested a variable declaration for the catch block, and throw
with an expression that set that variable.

/*type catch_variable*/
try {
throw expression; /*catch_variable = expression*/
} catch (type catch_variable) {
}

After suggesting this, I realize that in my code just throw without
any expression was sufficient. And I could emulate 100% with simple macros.

So basically this is my suggestion:

# define try if (1)
# define catch else catch_label:
# define throw do { goto catch_label; } while (0)

int main() {
try {
throw;
}
catch {
printf("catch\n");
}
printf("continue\n");
}

On 03/05/2021 19:55, Thiago Adams wrote:
> On Sunday, May 2, 2021 at 2:10:03 PM UTC-3, Bart wrote:
>> On 02/05/2021 14:29, Ben Bacarisse wrote:
>>> Thiago Adams <thiago...@gmail.com> writes:
>>>
>>>> On Saturday, May 1, 2021 at 5:29:42 PM UTC-3, Ben Bacarisse wrote:
>>>
>>>>> Are the people who will come along and read your code as happy with them
>>>>> as you are?
>>>
>>>>> I would re-write this exactly as I did the other example. The locality
>>>>> of declaration is not worth the ensuing mess.
>>>>
>>>> I think the point is the insertion of other declarations and/or statements
>>>> between two steps that can fail and needed to be checked.
>>>
>>> So even that was not the code that needed the macros. I thought it
>>> wouldn't be.
>> I don't know what the capabilies are of the OP's proposal for C. But I'd
>> have thought the advantages of conventional try/catch are clear.
>>
>> I rarely use exceptions and have only implemented them once (for
>> exceptions raised in user code). Using the same C-style syntax, they
>> might look like this:
>>
>> try {
>> ... any code ...
>> } catch (errorcode) {
>> ... deal with error
>> }
>>
>> The exception is thrown while executing the any-code block, but that
>> could be anywhere including deep inside a nested function:
>>
>> if (some error detected) throw (errorcode);
>>
>> So the advantage is that it can return directly from a nested function.
>> But also, that 'throw' statement could also be in inline code. Although
>> from the bits I've seen of the proposal, I think it needs a specific
>> errorcode (since this try-block might itself be executing unside another
>> try-block, or different errors could be thrown, needing catching
>> separately).
>>
>> I don't know how practical this would be to emulate in C. (I did my
>> version for an interpreted language where stack-unwinding was easy to
>> do. However I remember having to prohibit gotos in and out of a
>> try-block as it would have screwed things up.)
>
>
> The try-block I suggested is always local. throw must be inside the local
> try block. No need for stack-unwinding.
>
> I also suggested a variable declaration for the catch block, and throw
> with an expression that set that variable.
>
> /*type catch_variable*/
> try {
> throw expression; /*catch_variable = expression*/
> }
> catch (type catch_variable) {
> }
>
> After suggesting this, I realize that in my code just throw without
> any expression was sufficient. And I could emulate 100% with simple macros.
>
> So basically this is my suggestion:
>
> # define try if (1)
> # define catch else catch_label:
> # define throw do { goto catch_label; } while (0)
>
> int main() {
> try {
> throw;
> }
> catch {
> printf("catch\n");
> }
> printf("continue\n");
> }

This has some problems:

- You can't have more than one inside a function

- You can't nest them

- You can only catch one kind of error (but one than one needs multiple
'catch' per try; probably not essential here)

But I think the first of those, and perhaps the second, can be fixed by
introducing a code for each one:

# define try if (1)
# define catch(id) else catch_label##id:
# define throw(id) do { goto catch_label##id; } while (0)

int main(void) {
try {
throw(10);
}
catch(10) {
printf("catch 10\n");
}
printf("continue 20\n");

try {
throw(20);
}
catch(20) {
printf("catch 20\n");
}

printf("continue 20\n");
}

While the last might be done by redefining catch as:

# define catch(id) else if (0) catch_label##id:

Then you can have multiple catch blocks, each with a different ID.

(Note that whatever is passed as 'id' is literally pasted - maybe
there's a better of doing it. But it means you have to consistently use
either '10' or 'ten'; you can't mix them.)

On Monday, May 3, 2021 at 5:18:06 PM UTC-3, Bart wrote:
> On 03/05/2021 19:55, Thiago Adams wrote:
> > On Sunday, May 2, 2021 at 2:10:03 PM UTC-3, Bart wrote:
> >> On 02/05/2021 14:29, Ben Bacarisse wrote:
> >>> Thiago Adams <thiago...@gmail.com> writes:
> >>>
> >>>> On Saturday, May 1, 2021 at 5:29:42 PM UTC-3, Ben Bacarisse wrote:
> >>>
> >>>>> Are the people who will come along and read your code as happy with them
> >>>>> as you are?
> >>>
> >>>>> I would re-write this exactly as I did the other example. The locality
> >>>>> of declaration is not worth the ensuing mess.
> >>>>
> >>>> I think the point is the insertion of other declarations and/or statements
> >>>> between two steps that can fail and needed to be checked.
> >>>
> >>> So even that was not the code that needed the macros. I thought it
> >>> wouldn't be.
> >> I don't know what the capabilies are of the OP's proposal for C. But I'd
> >> have thought the advantages of conventional try/catch are clear.
> >>
> >> I rarely use exceptions and have only implemented them once (for
> >> exceptions raised in user code). Using the same C-style syntax, they
> >> might look like this:
> >>
> >> try {
> >> ... any code ...
> >> } catch (errorcode) {
> >> ... deal with error
> >> }
> >>
> >> The exception is thrown while executing the any-code block, but that
> >> could be anywhere including deep inside a nested function:
> >>
> >> if (some error detected) throw (errorcode);
> >>
> >> So the advantage is that it can return directly from a nested function.
> >> But also, that 'throw' statement could also be in inline code. Although
> >> from the bits I've seen of the proposal, I think it needs a specific
> >> errorcode (since this try-block might itself be executing unside another
> >> try-block, or different errors could be thrown, needing catching
> >> separately).
> >>
> >> I don't know how practical this would be to emulate in C. (I did my
> >> version for an interpreted language where stack-unwinding was easy to
> >> do. However I remember having to prohibit gotos in and out of a
> >> try-block as it would have screwed things up.)
> >
> >
> > The try-block I suggested is always local. throw must be inside the local
> > try block. No need for stack-unwinding.
> >
> > I also suggested a variable declaration for the catch block, and throw
> > with an expression that set that variable.
> >
> > /*type catch_variable*/
> > try {
> > throw expression; /*catch_variable = expression*/
> > }
> > catch (type catch_variable) {
> > }
> >
> > After suggesting this, I realize that in my code just throw without
> > any expression was sufficient. And I could emulate 100% with simple macros.
> >
> > So basically this is my suggestion:
> >
> > # define try if (1)
> > # define catch else catch_label:
> > # define throw do { goto catch_label; } while (0)
> >
> > int main() {
> > try {
> > throw;
> > }
> > catch {
> > printf("catch\n");
> > }
> > printf("continue\n");
> > }
> This has some problems:
>
> - You can't have more than one inside a function
>
> - You can't nest them
>
> - You can only catch one kind of error (but one than one needs multiple
> 'catch' per try; probably not essential here)

Yes, its not 100%. But I generally will have just one per function.

> But I think the first of those, and perhaps the second, can be fixed by
> introducing a code for each one:
> # define try if (1)
> # define catch(id) else catch_label##id:
> # define throw(id) do { goto catch_label##id; } while (0)
>
> int main(void) {
> try {
> throw(10);
> }
> catch(10) {
> printf("catch 10\n");
> }
> printf("continue 20\n");
>
> try {
> throw(20);
> }
> catch(20) {
> printf("catch 20\n");
> }
>
> printf("continue 20\n");
> }
>
> While the last might be done by redefining catch as:
>
> # define catch(id) else if (0) catch_label##id:
>
> Then you can have multiple catch blocks, each with a different ID.
>
> (Note that whatever is passed as 'id' is literally pasted - maybe
> there's a better of doing it. But it means you have to consistently use
> either '10' or 'ten'; you can't mix them.)

I prefer to pay the price for the limitation rater than add one ID each time.

(In my code generator this limitation does not exist because the id is generated)