Structured exceptions in C in avr-gcc?

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you, avr-gcc experts, have any tricks, recommendations etc. how to achieve structured exceptions (try-catch-finally-anything) in C in avr-gcc?

Thanks,

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Do you, avr-gcc experts, have any tricks, recommendations etc. how to achieve structured exceptions (try-catch-finally-anything) in C in avr-gcc?

Switch to C++ perhaps ? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Switch to C++ perhaps ? ;-)

Humm.

Okay, and how smooth/rough such transition might be, provided that I don't intend to use objects?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll leave it for others to comment (Johan?) as I stay well clear of the mysterious black art myself.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I'll leave it for others to comment (Johan?) as I stay well clear of the mysterious black art myself.

That did not sound like an encouragement... ;-)

Right now, I am using a combination of a label at the place where "finally" would come, and very carefully used goto-s as the exceptions. The natural drawback is, that I can't really "throw an exception" in called routines and have to "propagate" the error using global variables, which is rather cumbersome.

I though I am not the only one who encounters this from time to time as a real life problem...

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think this has been discussed at length in several threads. The forums search mechanism does not like the term "C++", but "exception handling" might work. You might also try the C++ sticky at the top of this form (you probably already did).

I also am not quite sure why it is not implemented, or how to handle it. My vague memories of the discussions centered on stack issues but I could be way off base here.

The common answer for newbies is, "don't do that -- you'll hurt yourself", but experienced people may have a better answer in store for them.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

try-catch-finally syntax is C++. For the C language version of that stuff, look into setjmp and longjmp which are found in , which is a standard C header file. You can find out more about it in the avr-libc user manual:
http://www.nongnu.org/avr-libc/u...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:
For the C language version of that stuff, look into setjmp and longjmp which are found in , which is a standard C header file. You can find out more about it in the avr-libc user manual:
http://www.nongnu.org/avr-libc/u...

Wow. Exactly the "don't do that" stuff, as it seems. There are days when I like just that... ;-)

Thanks a lot.

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'll leave it for others to comment (Johan?)

I've been driving it so hard that I'm the one mentioned? Oh dear...

Generally speaking, you should be able to compile C code with a C++ compiler and get the same result (or at least get generated code that has the same semantics). There are some places where C++ isn't backwards compatible with C (syntactically or semantically). As so often Google and Wikipedia is a great help:

http://en.wikipedia.org/wiki/Com...

If you are truly interested in the subject then put "C++ compatibility C" into Google and start exploring and reading.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well think hard what does try and catch do, and can you rewrite the functionality somehow, with macros or functions etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Generally speaking, you should be able to compile C code with a C++ compiler and get the same result (or at least get generated code that has the same semantics).

That's a (resemblance of :-) ) good news.

JohanEkdahl wrote:
If you are truly interested in the subject then put "C++ compatibility C" into Google and start exploring and reading.

This is exactly what I am eager to avoid.

EW opened new horizons to me with the setjmp stuff. I looked at the .S and found out that it's similar to what I was planning to write in the near future. As so often, I considered reinvention of the wheel.

Maybe a bit more cumbersome to use than try-finally, but it fulfills my expectations enough to avoid C++ for now.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

setjmp is high overhead versus a goto

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
setjmp is high overhead versus a goto

Sure, but it also has a different functionality.

Right now, from called/nested routines, I have to "propagate" an error "manually" via setting a global variable and a set of gotos and labels. setjmp() allows me to "jump out" from a nested set of routines right to the error processing.

This is a canonical example of exchanging efficiency for convenience.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

setjmp to fly off to a totally different function would be very confusing. Not what I'd do to clearly show exiting from nested loops within a single function.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve, steve, steve.

setjmp/longjmp are described as "non-local goto". Of course they are high overhead. Of course it is very confusing. But that is what they are designed to do, and they are also standard C library functions, and have been around for a long time. They were designed for exactly this reason: exception handling. It's just that C++ has a cleaner design with try-catch constructs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was going to post something along "I have concocted a pseudo __try/__finally/__throw using setjmp/longjmp", but I got frustrated by how I am unable to post a left bracket - exclamation mark - left bracket sequence.

Is it a known bug of this forum, or is it me?

JW

Attachment(s):