Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15193 > unrolled thread

Exception propagation in C

Back to article view | Back to comp.lang.c

Contents

  Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-29 09:52 -0800
    Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2011-12-29 19:40 +0100
      Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-29 14:03 -0600
    Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-29 13:07 -0600
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 13:38 -0800
        Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-30 20:24 -0600
          Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 02:19 -0800
            Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-03 14:04 -0600
              Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-04 04:26 -0800
                Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-06 14:05 -0600
                  Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-06 23:54 +0100
                    Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-06 22:24 -0600
                      Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-07 09:15 +0100
                        Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-08 23:45 -0600
                    Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 12:52 -0800
                  Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 14:20 -0800
                    Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-09 00:19 +0100
                      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 21:12 -0800
                        Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-08 23:41 -0600
                          Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-09 11:00 -0800
                            Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-10 00:42 -0600
                              Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-11 07:40 +0000
                              Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-11 12:59 -0800
                        Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-09 00:05 -0600
                          Re: Exception propagation in C Ian Collins <ian-news@hotmail.com> - 2012-01-09 20:40 +1300
                            Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-09 04:53 -0600
                              Re: Exception propagation in C 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-09 05:49 -0800
                    Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-08 17:29 -0600
                      Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-09 00:37 +0100
                      Re: Exception propagation in C Nomen Nescio <nobody@dizum.com> - 2012-01-09 11:36 +0100
                        Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-09 11:08 -0800
            Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-05 01:25 -0600
              Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-05 09:18 -0800
        Re: Exception propagation in C "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2011-12-30 21:20 -0800
          Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-31 06:19 -0500
          Re: Exception propagation in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 10:32 -0800
        Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-31 05:53 -0500
          Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-01 16:30 -0800
            Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 01:50 -0500
              Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-02 02:03 -0600
                Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 15:59 -0500
                  Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 04:12 -0800
                  Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-04 23:53 -0600
                    Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-05 06:45 -0500
              Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 04:16 -0800
                Re: Exception propagation in C Keith Thompson <kst-u@mib.org> - 2012-01-03 11:50 -0800
        Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2011-12-31 13:40 +0100
          Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-31 10:40 -0600
            Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-02 16:49 +0100
              Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-02 13:02 -0600
                Re: Exception propagation in C Dr Nick <3-nospam@temporary-address.org.uk> - 2012-01-02 19:53 +0000
                  Re: Exception propagation in C ImpalerCore <jadill33@gmail.com> - 2012-01-02 13:10 -0800
                Re: Exception propagation in C ImpalerCore <jadill33@gmail.com> - 2012-01-02 12:58 -0800
                Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-04 18:01 +0100
                  Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-06 14:38 -0600
                    Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-06 21:40 -0500
    Re: Exception propagation in C Kaz Kylheku <kaz@kylheku.com> - 2011-12-29 21:02 +0000
      Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2011-12-30 10:38 +0100
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 14:38 -0800
    Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-29 18:37 -0500
    Re: Exception propagation in C "BartC" <bc@freeuk.com> - 2011-12-30 01:07 +0000
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 14:07 -0800
    Re: Exception propagation in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-30 17:53 -0500
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 03:56 -0800
    Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-02 09:49 +0000
      Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-02 10:51 +0000
        Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 16:01 -0500
          Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-03 11:14 +0000
        Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 03:59 -0800
          Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-03 12:09 +0000
    Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-03 21:25 +0000
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-02-15 14:24 -0800
        Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-02-17 22:38 +0000

Page 4 of 4 — ← Prev page 1 2 3 [4]

#15223

"James Harris" <james.harris.1@googlemail.com> wrote in message
news:99fbedd4-b37f-4ced-8759-4ba9656259dc@m7g2000vbc.googlegroups.com...

> * Option 1. Use setjmp/longjmp. Not too good as, to be compatible,

> * Option 2. Traditional exception handling. As used in other languages

> * Option 3. The function detecting an exception creates an exception

What sort of syntax did you have in mind to make use of this:

Presumably something will be needed at the top level, to let the exception
handler know where to return to. And something in the lower level to invoke
the exception (I assume this will be the result of some test or failure in
software).

I don't have any ideas, just interested in how this might be done myself.
Particularly of what clean-up is (or isn't) done of the intermediate
functions which may have allocated or opened resources that need taking care
of.

> Unfortunately option 3 would mean use of goto.

I suspect some of the solutions will involve a lot worse than goto.

(FWIW I achieve something similar (error recovery) by using inline assembly
then:

o Saving Stack, Frame registers, and storing a recovery label address (in
this same function) in a global variable

o Starting the process (calling the functions) where the error might occur

o When the error occurs, jumping to the recovery point (more inline
assembly), where the Stack and Frame registers are restored.

No resources are released here either, but the program is usually about to
end anyway so is not critical.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#15234

On Dec 30, 1:07 am, "BartC" <b...@freeuk.com> wrote:
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> news:99fbedd4-b37f-4ced-8759-4ba9656259dc@m7g2000vbc.googlegroups.com...
>
> > * Option 1. Use setjmp/longjmp. Not too good as, to be compatible,
> > * Option 2. Traditional exception handling. As used in other languages
> > * Option 3. The function detecting an exception creates an exception
>
> What sort of syntax did you have in mind to make use of this:

No special syntax. Just standard C.

> Presumably something will be needed at the top level, to let the exception
> handler know where to return to.

Not as such. Each routine would decide what to do. In the general case
there would need to be some default response at the top level.

> And something in the lower level to invoke
> the exception (I assume this will be the result of some test or failure in
> software).

Yes, the lower level that detected the exception would create an
object to describe it. I've no idea yet what format the exception
object would take. I need to find out what others have done.

> I don't have any ideas, just interested in how this might be done myself.
> Particularly of what clean-up is (or isn't) done of the intermediate
> functions which may have allocated or opened resources that need taking care
> of.

The beauty of it is that each function would be responsible for
cleaning up its own resources.

No, the main beauty of it is that it will work with different
languages and even between languages. That's particularly important
for what I have in mind.

Check out the example code I posted in response to BGB.

> > Unfortunately option 3 would mean use of goto.
>
> I suspect some of the solutions will involve a lot worse than goto.

:-) I'm beginning to see this is very true.

James

[toc] | [prev] | [next] | [standalone]

#15236

On 12/29/2011 12:52 PM, James Harris wrote:
> Below is a suggestion for handling - more accurately, propagating -
> exceptions in C. It is intended for overall program performance though
> it goes against a preference of many including me. Can anyone come up
> with a faster or better way to propagate exceptions? What other ways
> are there to handle exceptions in C? What do you do? (I tend to detect
> exceptions where they occur by checking return values but I have never
> had a good way in C to get them to propagate.)

     Maybe this is clear to you already, but the words you use leave
me in some doubt: In pondering the performance of an exception scheme
one should not worry about how fast exceptions are handled, but about
how fast non-exceptions are not-handled.  If you make a million calls
to malloc() and get an exception on one of them, it's the performance
of the other 999,999 that you need to consider.

     They're called "exceptions," not "usuals."

> The issue is the desire to have exception propagation using *standard*
> C. I'm not talking principally about detecting exceptions but of a way
> for nested functions to signal an exception and have that exception
> propagate back along the call chain to a function that is set up to
> handle it.
>
> * Option 1. Use setjmp/longjmp. Not too good as, to be compatible,
> they need to be used in an if or a switch statement IIRC which can be
> inconvenient. Don't they also need a separate jump buffer for each
> active setjmp? I have used them in the past but found them awkward.

     This is how all the "pure C" exception frameworks I've seen have
worked.  Yes, it requires a dedicated jmp_buf for each target.  It
can also require that some variables in the setjmp() caller be made
`volatile', which is easy to forget to do *and* may prevent some of
the optimizer's more imaginative transformations -- that is, it may
slow down the more important, non-exception path.

> * Option 2. Traditional exception handling. As used in other languages
> this unwinds the stack of function calls looking for a handler. I
> cannot think of a way to implement that in C. Furthermore, it might be
> slow for two reasons: 1) the need to push and pop sufficient context
> for the exception handler to recognise where a given exception should
> be caught, 2) the consequent loss of sync between the stack and the
> CPU's branch prediction for returns. (A return would go back to
> somewhere other than where it was called from potentially impacting
> the performance of the rest of the calls on the call stack.) The
> latter is OK if exceptions are infrequent but is not generally
> applicable.

     The only portable ways to unwind the stack are to return or to
use longjmp().  With the latter there's no way to unwind the stack
frames one by one, nor to inspect what's being unwound: You just
longjmp() to the next-higher handler, do whatever local cleanup's
needed, longjmp() again to a handler higher still, and so on until
somebody's local cleanup says "This exception has propagated far enough; 
I'm absorbing it."

     Again, I feel you're worrying about performance in a situation
where performance is not very important.

> * Option 3. The function detecting an exception creates an exception
> object and sets an exception type in a thread-specific variable. Any
> calling functions, after each call (or group of calls) test that
> variable. If non-zero they jump to a local exception handler if there
> is one or jump to a return from the current function if not. This does
> involve a test and branch for each call but that is very fast (fusible
> and single cycle) and it avoids the need for exception handling
> context to be pushed and popped. It would also preserve the branch
> prediction of calls and returns.

     Isn't this just an `errno' equivalent, with a pointer instead
of an `int'?  In "The Standard C Library," PJ Plauger writes

	Nobody likes errno or the machinery that it implies. I can't
	recall anybody defending this approach to error reporting,
	not in two dozen or more meetings of X3J11, the committee
	that developed the C Standard. Several alternatives were
	proposed over the years. At least one faction favored simply
	discarding errno.

I'd hesitate before imitating an interface nobody likes ...

     Also, the performance probably suffers.  For all its drawbacks,
the function-returns-a-distinguishable-value-on-failure approach has
the advantage that the value is very likely in a CPU register when
you need to test it, not in a global variable somewhere off in RAM.

> [...] Anyone know of
> something better?

     I've seen various exception-like frameworks overlaid on C, some
down-and-dirty, some fairly elaborate.  All of them, however useful
for the particular task at hand, suffered from lack of support by
the language itself: There's just no way to tell the compiler that
a function might throw an exception, which means the compiler can't
tell the programmer when he's forgotten to catch one.  Somebody opens
a file, obtains values from various accessor functions and writes them
to the file, closes the stream, and returns -- except that one of the
accessors throws an exception that gets caught somewhere way up the
stack, and the file-writing function never closes its stream ...

     Errors of this kind can be prevented by programmer discipline,
but I've seen no scheme that will help keep the programmer on the
strait and narrow path.  This is sad, because it means an exception
mechanism that was supposed to make the programmer's job easier can
wind up making it more burdensome -- and more perilous.

     Exceptions aren't something you can just bolt on to a language.
Well, actually, you *can*: people have bolted them on to C, over and
over again.  Yet none of the various schemes has caught on, which I
think should cause you to ponder.  Maybe it's because bolting on is
a poor substitute for baking in.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15361

On Dec 30 2011, 10:53 pm, Eric Sosman <esos...@ieee-dot-org.invalid>
wrote:
> On 12/29/2011 12:52 PM, James Harris wrote:
>
> > Below is a suggestion for handling - more accurately, propagating -
> > exceptions in C. It is intended for overall program performance though
> > it goes against a preference of many including me. Can anyone come up
> > with a faster or better way to propagate exceptions? What other ways
> > are there to handle exceptions in C? What do you do? (I tend to detect
> > exceptions where they occur by checking return values but I have never
> > had a good way in C to get them to propagate.)
>
>      Maybe this is clear to you already, but the words you use leave
> me in some doubt: In pondering the performance of an exception scheme
> one should not worry about how fast exceptions are handled, but about
> how fast non-exceptions are not-handled.  If you make a million calls
> to malloc() and get an exception on one of them, it's the performance
> of the other 999,999 that you need to consider.
>
>      They're called "exceptions," not "usuals."

I'm principally thinking of overall performance. I did say that but I
can see my later comments could be taken to mean the opposite. There
is small caveat below but unless an exception is repeatedly generated
in a loop them the time it takes to generate or propagate tends to
zero and becomes insignificant.

Perhaps it's better expressed as: what's the fastest way in standard C
to ignore non-exceptions (still not a good phrase but you know what I
mean) while still reliably propagating and handling exceptions.

The caveat is that the design of C and its libraries may overuse
return values where exceptions, if available, would be a better
choice. So it may be hard for me to convince people on a C newsgroup
that invalid return values are not the best thing since sliced bread!

Exceptions should probably always be unusual but there are cases where
they could be beneficially used instead of invalid values.

...

>      The only portable ways to unwind the stack are to return or to
> use longjmp().  With the latter there's no way to unwind the stack
> frames one by one, nor to inspect what's being unwound: You just
> longjmp() to the next-higher handler, do whatever local cleanup's
> needed, longjmp() again to a handler higher still, and so on until
> somebody's local cleanup says "This exception has propagated far enough;
> I'm absorbing it."

For me, this paragraph sums it up. While a single longjmp back to main
would be very fast, in the general case a hierarchy of setjmps and
longjmps would be far too slow.

The only other portable option of returning can be made fast (very
fast) using option 3.

>      Again, I feel you're worrying about performance in a situation
> where performance is not very important.
>
> > * Option 3. The function detecting an exception creates an exception
> > object and sets an exception type in a thread-specific variable. Any
> > calling functions, after each call (or group of calls) test that
> > variable. If non-zero they jump to a local exception handler if there
> > is one or jump to a return from the current function if not. This does
> > involve a test and branch for each call but that is very fast (fusible
> > and single cycle) and it avoids the need for exception handling
> > context to be pushed and popped. It would also preserve the branch
> > prediction of calls and returns.
>
>      Isn't this just an `errno' equivalent, with a pointer instead
> of an `int'?  In "The Standard C Library," PJ Plauger writes
>
>         Nobody likes errno or the machinery that it implies. I can't
>         recall anybody defending this approach to error reporting,
>         not in two dozen or more meetings of X3J11, the committee
>         that developed the C Standard. Several alternatives were
>         proposed over the years. At least one faction favored simply
>         discarding errno.
>
> I'd hesitate before imitating an interface nobody likes ...

This is not the same as errno and does not use the same 'machinery'.
errno can be ignored and provides no instance data (such as what
specifically went wrong?). The value of errno, if potentially wanted,
must be saved before another call is made as it may be overwriten. An
exception, on the other hand, is something that should record specific
data and cause an immediate change in the processing path.exceptions

I chose TLS since that's the 'right' place for an exception condition.
Once an exception occurs the thread itself needs to sit up and take
notice, not just one routine, not just part of the thread, and not the
whole process.

As mentioned in reply to BGB, though, if not running multiple threads
a global could be used instead of TLS. I'm not advocating general use
of globals. They carry state between routines and break interfaces
which is a very bad idea. This, however, is an exception indication
that applies to the locus of control wherever it happens to be in the
single-threaded process. The alternative of adding an explicit
exception-return parameter from each called routine is also good but I
doubt most C programmers would like it as it's so unfamiliar.

>      Also, the performance probably suffers.  For all its drawbacks,
> the function-returns-a-distinguishable-value-on-failure approach has
> the advantage that the value is very likely in a CPU register when
> you need to test it, not in a global variable somewhere off in RAM.

I disagree here. As with the case at the top, performance is only an
issue if code is executed repeatedly. If being run repeatedly the
variable would normally be in L1 cache. Consider the proposed x86-32
code following a call to a routine.

  cmp [thread_excep], 0
  jnz exception_handler

Given this being executed in a loop the only normal way for
thread_excep not to be cached would be if there was extreme contention
for cache capacity. If that were the case a lot of things would be
slow and, again, this sequence would tend to become insignificant.

As well as thread_excep being cached, the branch would nearly always
fall through (be not taken) so is an ideal case for branch prediction
to correctly predict as not taken. Finally, the two instructions may
be fusible into one operation.

In other words, there's almost zero cost to this sequence.

The main negative to me is that, in C, it uses a goto but this hasn't
elicited the chorus of disapproval that I thought it might.

> > [...] Anyone know of
> > something better?
>
>      I've seen various exception-like frameworks overlaid on C, some
> down-and-dirty, some fairly elaborate.  All of them, however useful
> for the particular task at hand, suffered from lack of support by
> the language itself: There's just no way to tell the compiler that
> a function might throw an exception, which means the compiler can't
> tell the programmer when he's forgotten to catch one.  Somebody opens
> a file, obtains values from various accessor functions and writes them
> to the file, closes the stream, and returns -- except that one of the
> accessors throws an exception that gets caught somewhere way up the
> stack, and the file-writing function never closes its stream ...
>
>      Errors of this kind can be prevented by programmer discipline,
> but I've seen no scheme that will help keep the programmer on the
> strait and narrow path.  This is sad, because it means an exception
> mechanism that was supposed to make the programmer's job easier can
> wind up making it more burdensome -- and more perilous.
>
>      Exceptions aren't something you can just bolt on to a language.
> Well, actually, you *can*: people have bolted them on to C, over and
> over again.  Yet none of the various schemes has caught on, which I
> think should cause you to ponder.  Maybe it's because bolting on is
> a poor substitute for baking in.

Agreed. Inbuilt is better in so many ways. However, we have to work
with what there is available. C is C, after all, and I don't want to
mess with C-with-extensions whether they are plusses or something
else!

James

[toc] | [prev] | [next] | [standalone]

#15307

In article <99fbedd4-b37f-4ced-8759-4ba9656259dc@m7g2000vbc.googlegroups.com>,
James Harris  <james.harris.1@googlemail.com> wrote:
>Can anyone come up with a faster or better way to propagate exceptions?
>What other ways are there to handle exceptions in C? What do you do?

I worked at a place where the coding guidelines said
'every function returns an int, and that's the error code'.

[toc] | [prev] | [next] | [standalone]

#15314

On Mon, 02 Jan 2012 09:49:32 +0000, Joe keane saw fit to publish the
following:

> In article
> <99fbedd4-b37f-4ced-8759-4ba9656259dc@m7g2000vbc.googlegroups.com>,
> James Harris  <james.harris.1@googlemail.com> wrote:
>>Can anyone come up with a faster or better way to propagate exceptions?
>>What other ways are there to handle exceptions in C? What do you do?
> 
> I worked at a place where the coding guidelines said 'every function
> returns an int, and that's the error code'.

So have I, and i must say I much preferred it to the place i worked
where it was deemed acceptable to silently fail and return nothing. At
least the former delivered stable code which was easy to trace and debug.

Hurray for returning error codes!

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
		-- Kirk, "The Menagerie", stardate 3012.4

[toc] | [prev] | [next] | [standalone]

#15336

"Kleuske" <kleuske@nowhere.net> wrote in message
news:jds27t$423$3@dont-email.me...
> On Mon, 02 Jan 2012 09:49:32 +0000, Joe keane saw fit to publish the
> following:
>
> > In article
> > <99fbedd4-b37f-4ced-8759-4ba9656259dc@m7g2000vbc.googlegroups.com>,
> > James Harris  <james.harris.1@googlemail.com> wrote:
> >>Can anyone come up with a faster or better way to propagate exceptions?
> >>What other ways are there to handle exceptions in C? What do you do?
> >
> > I worked at a place where the coding guidelines said 'every function
> > returns an int, and that's the error code'.
>
> So have I, and i must say I much preferred it to the place i worked
> where it was deemed acceptable to silently fail and return nothing. At
> least the former delivered stable code which was easy to trace and debug.
>
> Hurray for returning error codes!
>

I'm curious.  In response to not being able to return other items, what did
you guys do?  Did you guys also pass in an additional variable(s) to every
procedure or almost every procedure?  E.g., an error structure, or a
function number?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#15359

On Mon, 02 Jan 2012 16:01:26 -0500, Rod Pemberton saw fit to publish the
following:

> "Kleuske" <kleuske@nowhere.net> wrote in message
> news:jds27t$423$3@dont-email.me...
>> On Mon, 02 Jan 2012 09:49:32 +0000, Joe keane saw fit to publish the
>> following:
>>
>> > In article
>> > <99fbedd4-b37f-4ced-8759-4ba9656259dc@m7g2000vbc.googlegroups.com>,
>> > James Harris  <james.harris.1@googlemail.com> wrote:
>> >>Can anyone come up with a faster or better way to propagate
>> >>exceptions? What other ways are there to handle exceptions in C? What
>> >>do you do?
>> >
>> > I worked at a place where the coding guidelines said 'every function
>> > returns an int, and that's the error code'.
>>
>> So have I, and i must say I much preferred it to the place i worked
>> where it was deemed acceptable to silently fail and return nothing. At
>> least the former delivered stable code which was easy to trace and
>> debug.
>>
>> Hurray for returning error codes!
>>
>>
> I'm curious.  In response to not being able to return other items, what
> did you guys do?

Given the problem domain (controlling hugely expensive equipment very, very,
VERY accurately), there wasn't any big need to return all kinds of
stuff, but there's always the possibility to pass a pointer in the argument
list and return results through that. Stability and correctness was the prime
concern, everything else was rather less important.

>  Did you guys also pass in an additional variable(s) to
> every procedure or almost every procedure?  E.g., an error structure, or
> a function number?

Error structures? Nope. Not really. Other variables passed by pointer in order
to return results? Occasionally, but there wasn't any big need for that. The
flow of information was a rather one-way affair.

I should have mentioned it wasn't your average piece of software and should
have qualified my remarks to reflect that.

-- 
It would seem that evil retreats when forcibly confronted.
		-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5

[toc] | [prev] | [next] | [standalone]

#15362

On Jan 2, 10:51 am, Kleuske <kleu...@nowhere.net> wrote:
> On Mon, 02 Jan 2012 09:49:32 +0000, Joe keane saw fit to publish the
> following:
>
> > In article
> > <99fbedd4-b37f-4ced-8759-4ba965625...@m7g2000vbc.googlegroups.com>,
> > James Harris  <james.harri...@googlemail.com> wrote:
> >>Can anyone come up with a faster or better way to propagate exceptions?
> >>What other ways are there to handle exceptions in C? What do you do?
>
> > I worked at a place where the coding guidelines said 'every function
> > returns an int, and that's the error code'.
>
> So have I, and i must say I much preferred it to the place i worked
> where it was deemed acceptable to silently fail and return nothing. At
> least the former delivered stable code which was easy to trace and debug.
>
> Hurray for returning error codes!

What did you guys return if an exception occurred in an exception
handler?

James

[toc] | [prev] | [next] | [standalone]

#15363

On Tue, 03 Jan 2012 03:59:27 -0800, James Harris saw fit to publish the
following:

> On Jan 2, 10:51 am, Kleuske <kleu...@nowhere.net> wrote:
>> On Mon, 02 Jan 2012 09:49:32 +0000, Joe keane saw fit to publish the
>> following:
>>
>> > In article
>> > <99fbedd4-b37f-4ced-8759-4ba965625...@m7g2000vbc.googlegroups.com>,
>> > James Harris  <james.harri...@googlemail.com> wrote:
>> >>Can anyone come up with a faster or better way to propagate
>> >>exceptions? What other ways are there to handle exceptions in C? What
>> >>do you do?
>>
>> > I worked at a place where the coding guidelines said 'every function
>> > returns an int, and that's the error code'.
>>
>> So have I, and i must say I much preferred it to the place i worked
>> where it was deemed acceptable to silently fail and return nothing. At
>> least the former delivered stable code which was easy to trace and
>> debug.
>>
>> Hurray for returning error codes!
> 
> What did you guys return if an exception occurred in an exception
> handler?

Lacking exception handlers, the question did not arise. In case of error
in that subsystem, the machine just freezes, in order to prevent damage
to the expensive (think jet-fighter price-range) equipment.

I remember celebrating the first time the software ran for ten seconds
without freezing the machine. I got home a bit wobbly on that occasion.

-- 
Warp 7 -- It's a law we can live with.

[toc] | [prev] | [next] | [standalone]

#15387

In article <99fbedd4-b37f-4ced-8759-4ba9656259dc@m7g2000vbc.googlegroups.com>,
James Harris  <james.harris.1@googlemail.com> wrote:
>* Option 3. The function detecting an exception creates an exception
>object and sets an exception type in a thread-specific variable. Any
>calling functions, after each call (or group of calls) test that
>variable. If non-zero they jump to a local exception handler if there
>is one or jump to a return from the current function if not. This does
>involve a test and branch for each call but that is very fast (fusible
>and single cycle) and it avoids the need for exception handling
>context to be pushed and popped. It would also preserve the branch
>prediction of calls and returns.

I'm baffled as to why one would do that.

It's like using a global variable to pass information between a function
and a function it calls or the reverse.  Then you realize that it
doesn't work for multi-threaded and make it more complicated.

It still doesn't work when you get an exception, then the cleanup code
itself gets an exception.  [Of course, in some cases you just throw up
your hands and call abort(), but this often can be handled.]  Presumably
the callers want the -first- error code but you overwrote it.

If the stack works [or registers] why not use that?

[toc] | [prev] | [next] | [standalone]

#17403

On Jan 3, 9:25 pm, j...@panix.com (Joe keane) wrote:
> In article <99fbedd4-b37f-4ced-8759-4ba965625...@m7g2000vbc.googlegroups.com>,
> James Harris  <james.harri...@googlemail.com> wrote:
>
> >* Option 3. The function detecting an exception creates an exception
> >object and sets an exception type in a thread-specific variable. Any
> >calling functions, after each call (or group of calls) test that
> >variable. If non-zero they jump to a local exception handler if there
> >is one or jump to a return from the current function if not. This does
> >involve a test and branch for each call but that is very fast (fusible
> >and single cycle) and it avoids the need for exception handling
> >context to be pushed and popped. It would also preserve the branch
> >prediction of calls and returns.
>
> I'm baffled as to why one would do that.
>
> It's like using a global variable to pass information between a function
> and a function it calls or the reverse.  Then you realize that it
> doesn't work for multi-threaded and make it more complicated.

On the contrary. As proposed, this is a per-thread variable.

> It still doesn't work when you get an exception, then the cleanup code
> itself gets an exception.  [Of course, in some cases you just throw up
> your hands and call abort(), but this often can be handled.]  Presumably
> the callers want the -first- error code but you overwrote it.

If the cleanup code triggers an exception this is the situation that
was discussed earlier of what response is expected or best of three:
propagate the initial exception, propagate the new exception,
propagate both. The latter has its own questions. In the proposed
model the abort-type call should not be necessary or used in any
circumstances.

> If the stack works [or registers] why not use that?

The stack is a good option but does require explicit copying and
propagation of an exception indicator and may be slower to manage
where an exception has not occurred. Can you come up with a fast set
of instructions to manage exception indicators using the stack?
Registers may be a bad option as they are sometimes in short supply
and may be better used for general purpose use.

James

[toc] | [prev] | [next] | [standalone]

#17540

In article <dc463e61-5379-4ae2-b2f3-f9c341ebef91@hs8g2000vbb.googlegroups.com>,
James Harris  <james.harris.1@googlemail.com> wrote:
>The stack is a good option but does require explicit copying and
>propagation of an exception indicator and may be slower to manage
>where an exception has not occurred. Can you come up with a fast set
>of instructions to manage exception indicators using the stack?

Suppose you dedicate one register to be the 'alternate link'.

When you call a function, if there is no error, it should return to the
usual place (after the call instruction).  If there is an error, it
returns to the alternate address.  The alternate link can be set when
the function starts, or different for each calling site, as PC-relative.

On return from function, you can say use normal, use alternate, or test
r0 and let that decide.

This lets you write normal C code.  It's just an optimization.  When
people complain about a compare-and-branch for every function call, you
say 'no it isn't' and when they ask you wave your hands and say 'magic'.

>Registers may be a bad option as they are sometimes in short supply
>and may be better used for general purpose use.

That may be true.  I think it's easier to describe it with registers,
then how to do it with stack locations is straightforward.  Which is
better, dunno.

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c

csiph-web