Exceptions in C/C++

[opexoc]

Hello,

I have question concerning such code:

__try
{
...
} __except(EXCEPTION_EXECUTE_HANDLER)
{
printf("Exception code: %.8x\n", GetExceptionCode());
}


Is C related code? Or maybe C++?

opexoc

 

[Tor Rustad]

Hello,

I have question concerning such code:

__try
{
...
} __except(EXCEPTION_EXECUTE_HANDLER)
{
printf("Exception code: %.8x\n", GetExceptionCode());
}


Is C related code? Or maybe C++?

It's not ISO C, but Microsoft specific C, see their MSDN doc.

 

[opexoc]

So if I want to use exceptions catching in dev-cpp in C code then what
should I do?

 

[jacob navia]

So if I want to use exceptions catching in dev-cpp in C code then what
should I do?

If you use the lcc-win compiler you can use the
__try/__except construct.

URL below

 

[opexoc]

If you use the lcc-win compiler you can use the
__try/__except construct.

Ok but dec-cpp has any construct which is to catching exception for C
language?

 

[Francine.Neary]

If you use the lcc-win compiler you can use the
__try/__except construct.

URL below

Rather than using extensions that tie your code to a particular
compiler and platform, why not use the perfectly good exception-
handling features already present in standard C, namely setjmp()/
longjmp()?

 

[jacob navia]

Ok but dec-cpp has any construct which is to catching exception for C
language?

dev-cpp is an IDE. The compiler used is gcc in its "mingw" incarnation.
As fas as I know there isn't anything like that in gcc.

Therefore is not there for devcpp

 

[jacob navia]

Rather than using extensions that tie your code to a particular
compiler and platform, why not use the perfectly good exception-
handling features already present in standard C, namely setjmp()/
longjmp()?

because they do not do what exceptions do.

 

[dj3vande]

Rather than using extensions that tie your code to a particular
compiler and platform, why not use the perfectly good exception-
handling features already present in standard C, namely setjmp()/
longjmp()?

setjmp and longjmp are not exactly "perfectly good exception-handling
features"; setjmp is merely a restricted COME FROM, and longjmp marks
acceptable targets for it.

It's possible to build a perfectly good exception-handling system on
top of setjmp/longjmp, but it does have to be built.


dave

 

[Richard Tobin]

setjmp and longjmp are not exactly "perfectly good exception-handling
features"; setjmp is merely a restricted COME FROM, and longjmp marks
acceptable targets for it.

The whole point of COME FROM is that the jumped-from location isn't
marked.

-- Richard

 

[opexoc]

dev-cpp is an IDE. The compiler used is gcc in its "mingw" incarnation.
As fas as I know there isn't anything like that in gcc.

Therefore is not there for devcpp

So it is not possible to use exceptions catching in dev-cpp?

opexoc

 

[Mark McIntyre]

So it is not possible to use exceptions catching in dev-cpp?

Why don't you either
a) Read the Manual; or
b) ask in a dev-cpp newsgroup, mailing list etc etc?

This is NOT the right place.

 

[jacob navia]

So it is not possible to use exceptions catching in dev-cpp?

opexoc

I do not think so

 

[CBFalconer]

because they do not do what exceptions do.

Aha. Now you may be beginning to see why exceptions (as built into
the language) are off-topic on c.l.c. Hint: try c.l.c++, which
handles a language with such a feature.

 

[dj3vande]

The whole point of COME FROM is that the jumped-from location isn't
marked.

No, that was a side goal of the original implementation.
The point of COME FROM is that the destination of a jump (the location
of the COME FROM) can be changed on the fly for a particular origin
(target of the COME FROM); setjmp/longjmp require that the source and
destination be marked (and the longjmp needs to be wrapped in a test if
you want it to not jump until a setjmp has asked to COME FROM it), but
which setjmp a longjmp jumps to can be dynamically modified.


dave

 

[Malcolm McLean]

So it is not possible to use exceptions catching in dev-cpp?

try ... catch ... throw is a fairly common extension that both lcc-win and
Microsft's compiler seem to support. Opinions will differ on whether it is a
good idea.
One indisputable disadvantage is that you then cannot port code to any
arbitrary C platform. Though I've got considerable experience in C on a wide
variety of compilers and targets, I couldn't possibly list the
characteristics of each and every one on the market.

 

[Richard Tobin]

The whole point of COME FROM is that the jumped-from location isn't
marked.

[/QUOTE]

No, that was a side goal of the original implementation.
The point of COME FROM is that the destination of a jump (the location
of the COME FROM) can be changed on the fly for a particular origin
(target of the COME FROM); setjmp/longjmp require that the source and
destination be marked (and the longjmp needs to be wrapped in a test if
you want it to not jump until a setjmp has asked to COME FROM it), but
which setjmp a longjmp jumps to can be dynamically modified.

What you are describing seems more like ASSIGNED GO TO (provided in C
by a GNU extension). In all forms of GO TO, including longjmp(), the
jump destination is specified at the jump source by an argument of the
GO TO. In COME FROM, the jump source is specified at the jump
destination by an argument of the COME FROM. With setjmp()/longjmp()
there is no way to set the jump source at the jump destination (ie the
setjmp()).

Variability of one end of the jump is an orthogonal feature provided
by ASSIGNED GO TO and ASSIGNED COME FROM. It's not the difference
between GO TO and COME FROM.

-- Richard

 

[jacob navia]

Aha. Now you may be beginning to see why exceptions (as built into
the language) are off-topic on c.l.c. Hint: try c.l.c++, which
handles a language with such a feature.

It is not off topic. It is about exceptions in C.

Clear?

And if you do not like a subject, just skip it.

 

[Flash Gordon]

jacob navia wrote, On 08/12/07 12:18:

It is not off topic. It is about exceptions in C.

Clear?

OK, the answer is easy then, there aren't any.

The suggestion of trying C++ which *does* have exceptions was a sensible
one. The suggestion of asking somewhere where the compiler the OP was
interested in (which was not yours of MSVC++) was also sensible. The
suggestion of implementing something using setjmp/longjmp was sensible
since it allows staying with standard C (although it might not provide
the functionality wanted by the OP). Suggesting switching to a compiler
specific extension provided by a couple of other compilers does *not*
answer the OPs question.

And if you do not like a subject, just skip it.

If you don't like the subject of the group then just skip the group.

 

[jacob navia]

jacob navia wrote, On 08/12/07 12:18:

OK, the answer is easy then, there aren't any.

The suggestion of trying C++ which *does* have exceptions was a sensible
one. The suggestion of asking somewhere where the compiler the OP was
interested in (which was not yours of MSVC++) was also sensible. The
suggestion of implementing something using setjmp/longjmp was sensible
since it allows staying with standard C (although it might not provide
the functionality wanted by the OP). Suggesting switching to a compiler
specific extension provided by a couple of other compilers does *not*
answer the OPs question.


If you don't like the subject of the group then just skip the group.

The subject of the group is C. Nowhere in the charter was mentioned
that it was just ISO C.

Microsoft, lcc-win, and other compilers under windows implement
__try/__except. And if you do not like it it is your problem, not
mine. It is a common extension under windows.