How to exit out of a function ? what is try-catch-throw in terms of Program Counter

Discussion in 'C Programming' started by gnuist006@gmail.com, Oct 20, 2007.

  1. Guest

    I have some code like this:

    (if (test)
    (exit)
    (do something))


    or

    (if (test)
    ( do something)
    (exit))


    Various levels of nestings.

    I have several questions, basic to sophisticated.

    (1) What is the lisp equivalent idiom for (exit) as in bash or
    in C.
    (2) What is the best practice to handle this kind of problems?

    (3) What is the intermediate practice to handle this kind of
    problems.

    NOTE: I am really afraid of try-catch-throw. I have never been
    able to understand it since it does not exist in C and I cant
    really visualize the construct in terms of C. That is what my
    brain can process. If you understand it so well, you can show
    me how one would really implement that kind of construct in
    C and then by extension I can see that kind of program flow
    in LISP. Whether its imperative programming or functional,
    beneath there is program counter and assembly. C is close
    to machine so much that it is almost assembly. So understanding try-c-
    t in C is equivalent to understanding at
    the level of machine language.

    I therefore take the liberty to crosspost in C and C++ groups.
     
    , Oct 20, 2007
    #1
    1. Advertising

  2. Guest

    On Oct 20, 1:45 pm, wrote:
    > I have some code like this:
    >
    > (if (test)
    > (exit)
    > (do something))
    >
    > or
    >
    > (if (test)
    > ( do something)
    > (exit))
    >
    > Various levels of nestings.
    >
    > I have several questions, basic to sophisticated.
    >
    > (1) What is the lisp equivalent idiom for (exit) as in bash or
    > in C.
    > (2) What is the best practice to handle this kind of problems?
    >
    > (3) What is the intermediate practice to handle this kind of
    > problems.
    >
    > NOTE: I am really afraid of try-catch-throw. I have never been
    > able to understand it since it does not exist in C and I cant
    > really visualize the construct in terms of C. That is what my
    > brain can process. If you understand it so well, you can show
    > me how one would really implement that kind of construct in
    > C and then by extension I can see that kind of program flow
    > in LISP. Whether its imperative programming or functional,
    > beneath there is program counter and assembly. C is close
    > to machine so much that it is almost assembly. So understanding try-c-
    > t in C is equivalent to understanding at
    > the level of machine language.
    >
    > I therefore take the liberty to crosspost in C and C++ groups.


    Is there any explanation of try-catch-throw in terms of
    gotos than PC ? Is that explanation more simpler ?
     
    , Oct 20, 2007
    #2
    1. Advertising

  3. Re: How to exit out of a function ? what is try-catch-throw in termsof Program Counter

    * :
    > I have some code like this:
    >
    > (if (test)
    > (exit)
    > (do something))
    >
    >
    > or
    >
    > (if (test)
    > ( do something)
    > (exit))
    >
    >
    > Various levels of nestings.
    >
    > I have several questions, basic to sophisticated.
    >
    > (1) What is the lisp equivalent idiom for (exit) as in bash or
    > in C.


    C++ does not have a built-in 'exit' command. There is a library
    function 'exit' which exits the process. One must assume that's not
    what you mean, and that you're not asking C and C++ programmers to teach
    you Lisp.

    Therefore, assuming you want to exit the function or the block.


    > (2) What is the best practice to handle this kind of problems?


    It's not a general class of problem.

    Appropriate solutions depend on the problem at hand.

    E.g., in C++,

    // (if (test) (exit) (do something))

    void foo()
    {
    if( !test )
    {
    doSomething();
    }
    }

    void bar()
    {
    if( test ) { return; }
    doSomething();
    }



    > (3) What is the intermediate practice to handle this kind of
    > problems.


    ?


    > NOTE: I am really afraid of try-catch-throw. I have never been
    > able to understand it since it does not exist in C and I cant
    > really visualize the construct in terms of C. That is what my
    > brain can process. If you understand it so well, you can show
    > me how one would really implement that kind of construct in
    > C and then by extension I can see that kind of program flow
    > in LISP. Whether its imperative programming or functional,
    > beneath there is program counter and assembly. C is close
    > to machine so much that it is almost assembly. So understanding try-c-
    > t in C is equivalent to understanding at
    > the level of machine language.


    The closest equivalent in C would be a 'longjmp'. However, a C++
    exception is more limited, in that it will only jump up the call chain,
    and it's more powerful, in that it will destroy local objects as it does
    so. Also, if you use 'longjmp' in C++ you're practically doomed (unless
    you use it to jump between co-routines with their own stacks), because
    'longjmp' doesn't destroy local objects.



    > I therefore take the liberty to crosspost in C and C++ groups.


    Uh.

    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Oct 20, 2007
    #3
  4. Jim Langston Guest

    <> wrote in message
    news:...
    >I have some code like this:
    >
    > (if (test)
    > (exit)
    > (do something))
    >
    >
    > or
    >
    > (if (test)
    > ( do something)
    > (exit))
    >
    >
    > Various levels of nestings.
    >
    > I have several questions, basic to sophisticated.
    >
    > (1) What is the lisp equivalent idiom for (exit) as in bash or
    > in C.


    Your message post is asking "How to exit out of a function..." yet you are
    showing code that almost exits out of the program. exit() would do that.

    If you wish to exit out of the function then the correct keyword is return.
    Such as:

    if (condition)
    return;
    (do something)

    if ( condition )
    (do something )
    return;

    return can return a value if the function returns a value, such as
    return 1;
    return foo;
    return bar();
    etc..

    > (2) What is the best practice to handle this kind of problems?


    It depends on coding style. There is some coding style that states that any
    function will only have one return point. In which case you would do:

    if ( condition )
    ( do something )
    return;

    Personally, I chose to return early if it's what I would consider an error
    condition.

    if ( condition )
    return NULL;
    ( do something )
    return Value;

    There really is no best way, it depends on coding standard and how easy the
    code is to write, read and maintain.

    > (3) What is the intermediate practice to handle this kind of
    > problems.


    Again, it depends on the problems. At different times in my career I have
    gone with returning whenever I've wanted to to returning only at the very
    end.
    I find that huge if statments, however, make my code harder to write, read
    and maintain, so I will check for conditions early and return early if I
    can. I try not to return in the middle of a function, but only at the top
    or bottom. But it depends on the situation.

    > NOTE: I am really afraid of try-catch-throw. I have never been
    > able to understand it since it does not exist in C and I cant
    > really visualize the construct in terms of C. That is what my
    > brain can process. If you understand it so well, you can show
    > me how one would really implement that kind of construct in
    > C and then by extension I can see that kind of program flow
    > in LISP. Whether its imperative programming or functional,
    > beneath there is program counter and assembly. C is close
    > to machine so much that it is almost assembly. So understanding try-c-
    > t in C is equivalent to understanding at
    > the level of machine language.
    >
    > I therefore take the liberty to crosspost in C and C++ groups.


    As for try...catch blocks, I try to reserve those only for actual errors.
    One reason I have found I need to use them when a function is supposed to
    return a reference to an object, and that object doesn't exist. I have to
    return something, and something is not good enough. So I get around it by
    throwing out of the function.

    (Untested code)

    Player& FindPlayer( const std::string& Name, std::map<std::string, Player> )
    {
    std::map<std::string, Player>::iterator it = Player.find( Name );
    if ( it == Player.end() )
    {
    // Player was not found in map. Have to return something. Lets just
    throw.
    throw std::exception("Player not found");
    }
    return (*it).second;
    }

    int main()
    {
    // ...
    try
    {
    Player ThisPlayer& = FindPlayer( SomePlayer );
    // use ThisPlayer
    }
    castch ( std::exception e )
    {
    std::cout << "Player " << SomePlayer << " not found.\n";
    }
    }
     
    Jim Langston, Oct 21, 2007
    #4
  5. writes:
    > I have some code like this:
    >
    > (if (test)
    > (exit)
    > (do something))
    >
    >
    > or
    >
    > (if (test)
    > ( do something)
    > (exit))


    That's Lisp, yes? Saying so would be good, since we naturally assume
    that anything posted to comp.lang.c is C.

    > Various levels of nestings.
    >
    > I have several questions, basic to sophisticated.
    >
    > (1) What is the lisp equivalent idiom for (exit) as in bash or
    > in C.


    You're expecting C programmers to know what (exit) does in Lisp?

    [snip]

    > I therefore take the liberty to crosspost in C and C++ groups.


    That's rarely a good idea.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Oct 21, 2007
    #5
  6. <> wrote in message
    news:...
    >I have some code like this:
    >
    > (if (test)
    > (exit)
    > (do something))
    >
    >
    > or
    >
    > (if (test)
    > ( do something)
    > (exit))
    >
    >
    > Various levels of nestings.
    >
    > I have several questions, basic to sophisticated.
    >
    > (1) What is the lisp equivalent idiom for (exit) as in bash or
    > in C.
    > (2) What is the best practice to handle this kind of problems?
    >
    > (3) What is the intermediate practice to handle this kind of
    > problems.
    >
    > NOTE: I am really afraid of try-catch-throw. I have never been
    > able to understand it since it does not exist in C and I cant
    > really visualize the construct in terms of C. That is what my
    > brain can process. If you understand it so well, you can show
    > me how one would really implement that kind of construct in
    > C and then by extension I can see that kind of program flow
    > in LISP. Whether its imperative programming or functional,
    > beneath there is program counter and assembly. C is close
    > to machine so much that it is almost assembly. So understanding try-c-
    > t in C is equivalent to understanding at
    > the level of machine language.
    >
    > I therefore take the liberty to crosspost in C and C++ groups.
    >

    C++ compilers that compile to C will produce C code something like this

    C++

    double safesqrt(double x)
    {
    if(x < 0)
    throw "imaginary root";
    return sqrt(x);
    }

    double foo()
    {
    if( pow( sqrt(-1), sqrt(-1)) != exp(-M_PI/2) )
    printf("Stupid computer can't do basic maths\n");
    }

    int main(void)
    {
    try
    {
    foo();
    }
    catch(char * err)
    {
    printf("Sorry %s\n", err);
    }
    }

    C

    void * safesqsrt(int *type, double *ret, double x)
    {
    if(x < 0)
    {
    *type = CHARSTAR;
    return "imaginary root";
    }
    * ret = sqrt(x);
    return 0;
    }

    void *foo(int *type)
    {
    double temp;
    void *throw;
    int throwtype;

    throw = safesqrt(&throwtype, &temp, -1.0);
    if(throw)
    {
    *type - throwtype;
    return throw;
    }
    /* etc */
    }

    int main(void)
    {
    char *throw;
    int throwtype;
    char *err;

    throw = foo(&throwtype);
    if(throw)
    goto catch;
    return 0;
    catch:
    switch(throwtype)
    {
    case CHARSTAR:
    err = throw;
    printf("Sorry %s\n", err);
    break;
    }

    }

    As you see it is totally impractical to try to do this in handwritten C
    code for very long, though a compiler will happily chug through it. There
    are in fact more subtleties - local objects in foo() and safesqrt() have to
    be destroyed.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Oct 21, 2007
    #6
  7. In article <>,
    Keith Thompson <> wrote:
    > writes:
    >> I have some code like this:
    >>
    >> (if (test)
    >> (exit)
    >> (do something))
    >>
    >>
    >> or
    >>
    >> (if (test)
    >> ( do something)
    >> (exit))

    >
    >That's Lisp, yes? Saying so would be good, since we naturally assume
    >that anything posted to comp.lang.c is C.


    Actually, most of what is posted here is "not C". Since, according to
    many of the regulars, if it includes anything "off topic", it is "not C".

    Since all code used in the real world uses extensions, there is no C
    code in the real world.
     
    Kenny McCormack, Oct 21, 2007
    #7
  8. santosh Guest

    Kenny McCormack wrote:

    > In article <>,
    > Keith Thompson <> wrote:
    >> writes:
    >>> I have some code like this:
    >>>
    >>> (if (test)
    >>> (exit)
    >>> (do something))
    >>>
    >>>
    >>> or
    >>>
    >>> (if (test)
    >>> ( do something)
    >>> (exit))

    >>
    >>That's Lisp, yes? Saying so would be good, since we naturally assume
    >>that anything posted to comp.lang.c is C.

    >
    > Actually, most of what is posted here is "not C". Since, according to
    > many of the regulars, if it includes anything "off topic", it is "not
    > C".
    >
    > Since all code used in the real world uses extensions, there is no C
    > code in the real world.


    Perhaps you mean to say that there are no C _programs_ in the real
    world. I'm sure there are pieces of fully Standard C code in many, if
    not most programs. It's very likely though that the program, taken as a
    whole, includes some non-Standard C.
     
    santosh, Oct 21, 2007
    #8
  9. In article <fffb72$fel$>, santosh <> wrote:
    >Kenny McCormack wrote:
    >
    >> In article <>,
    >> Keith Thompson <> wrote:
    >>> writes:
    >>>> I have some code like this:
    >>>>
    >>>> (if (test)
    >>>> (exit)
    >>>> (do something))
    >>>>
    >>>>
    >>>> or
    >>>>
    >>>> (if (test)
    >>>> ( do something)
    >>>> (exit))
    >>>
    >>>That's Lisp, yes? Saying so would be good, since we naturally assume
    >>>that anything posted to comp.lang.c is C.

    >>
    >> Actually, most of what is posted here is "not C". Since, according to
    >> many of the regulars, if it includes anything "off topic", it is "not
    >> C".
    >>
    >> Since all code used in the real world uses extensions, there is no C
    >> code in the real world.

    >
    >Perhaps you mean to say that there are no C _programs_ in the real
    >world. I'm sure there are pieces of fully Standard C code in many, if
    >not most programs. It's very likely though that the program, taken as a
    >whole, includes some non-Standard C.


    No. I meant what I said. I'm not saying that everybody feels this way,
    but more than a couple of the CLC regs have posted exactly that. That one
    bit of "non-portable" code makes the whole thing something other than "C".
     
    Kenny McCormack, Oct 21, 2007
    #9
  10. "Kenny McCormack" <> wrote in message
    >
    > Since all code used in the real world uses extensions, there is no C
    > code in the real world.
    >

    Sort of true. You'll find a non-trivial program on my website to build fuzzy
    logic trees. It is written in pure ANSI C89 except for one detail. The
    comma-separated value file loader uses nan to indicate missing values.
    Missing values are not allowed in the program, so it plays almost no part in
    the main flow control. But it loads, checks for nans, and rejects if they
    are present.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Oct 21, 2007
    #10
  11. [Followup corrected to clc]

    santosh said:

    > Kenny McCormack wrote:
    >

    <snip>

    >> Since all code used in the real world uses extensions, there is no C
    >> code in the real world.

    >
    > Perhaps you mean to say that there are no C _programs_ in the real
    > world.


    Even if that's what he meant, he's still wrong.

    <snip>

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Oct 21, 2007
    #11
  12. In article <>,
    Malcolm McLean <> wrote:
    >
    >"Kenny McCormack" <> wrote in message
    >>
    >> Since all code used in the real world uses extensions, there is no C
    >> code in the real world.
    >>

    >Sort of true. You'll find a non-trivial program on my website to build fuzzy
    >logic trees. It is written in pure ANSI C89 except for one detail. The
    >comma-separated value file loader uses nan to indicate missing values.
    >Missing values are not allowed in the program, so it plays almost no part in
    >the main flow control. But it loads, checks for nans, and rejects if they
    >are present.


    Obviously, the statement that "_all_ code used in the real world..."
    is false in the mathematical sense of the word "all", but it is true in
    the normal sense of the word "all".

    But here's the thing: I seriously doubt that, in the hosted world (at
    any rate), anything that can be written in "ISO C" (or whatever term you
    prefer) should be. I.e., anything that is that pure (such as your fuzzy
    logic program) could be written much more easily and readably in
    something like AWK.
     
    Kenny McCormack, Oct 21, 2007
    #12
  13. santosh Guest

    Kenny McCormack wrote:

    <snip>

    > But here's the thing: I seriously doubt that, in the hosted world (at
    > any rate), anything that can be written in "ISO C" [ ... ]


    Lookup libraries like libTomCrypt, libTomMath etc. Many applications
    that do "number crunching", by and large, can be, and often are,
    written in Standard C.
     
    santosh, Oct 21, 2007
    #13
  14. abhy Guest

    On Oct 21, 1:45 am, wrote:
    > I have some code like this:
    >
    > (if (test)
    > (exit)
    > (do something))
    >
    > or
    >
    > (if (test)
    > ( do something)
    > (exit))
    >
    > Various levels of nestings.
    >
    > I have several questions, basic to sophisticated.
    >
    > (1) What is the lisp equivalent idiom for (exit) as in bash or
    > in C.
    > (2) What is the best practice to handle this kind of problems?
    >
    > (3) What is the intermediate practice to handle this kind of
    > problems.
    >
    > NOTE: I am really afraid of try-catch-throw. I have never been
    > able to understand it since it does not exist in C and I cant
    > really visualize the construct in terms of C. That is what my
    > brain can process. If you understand it so well, you can show
    > me how one would really implement that kind of construct in
    > C and then by extension I can see that kind of program flow
    > in LISP. Whether its imperative programming or functional,
    > beneath there is program counter and assembly. C is close
    > to machine so much that it is almost assembly. So understanding try-c-
    > t in C is equivalent to understanding at
    > the level of machine language.
    >
    > I therefore take the liberty to crosspost in C and C++ groups.


    ok i guess we coudl write this one like as below.

    if(test)
    do something

    else
    exit


    does this solve u r problem..?
    If u want to exit from program exit is the keyword..if u want to break
    from loops break is the key word.
     
    abhy, Oct 21, 2007
    #14
  15. "Kenny McCormack" <> wrote in message
    >
    > But here's the thing: I seriously doubt that, in the hosted world (at
    > any rate), anything that can be written in "ISO C" (or whatever term you
    > prefer) should be. I.e., anything that is that pure (such as your fuzzy
    > logic program) could be written much more easily and readably in
    > something like AWK.
    >

    I don't know AWK. If you've got time, try doing it. Seriously. I am not in
    the business of selling C compilers, and if fuzzy logic trees are better
    implemented in another language I'd be glad to be aware of it.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Oct 21, 2007
    #15
  16. santosh Guest

    abhy wrote:

    <snip>

    > If u want to exit from program exit is the keyword..


    C has no keyword called exit. exit() is a Standard library function.
     
    santosh, Oct 21, 2007
    #16
  17. In article <>,
    Malcolm McLean <> wrote:
    >
    >"Kenny McCormack" <> wrote in message
    >>
    >> But here's the thing: I seriously doubt that, in the hosted world (at
    >> any rate), anything that can be written in "ISO C" (or whatever term you
    >> prefer) should be. I.e., anything that is that pure (such as your fuzzy
    >> logic program) could be written much more easily and readably in
    >> something like AWK.
    >>

    >I don't know AWK. If you've got time, try doing it. Seriously. I am not in
    >the business of selling C compilers, and if fuzzy logic trees are better
    >implemented in another language I'd be glad to be aware of it.


    I may just do that. No promises, but I might get around to it at some
    point.
     
    Kenny McCormack, Oct 21, 2007
    #17
  18. On Sun, 21 Oct 2007 18:39:13 +0100, in comp.lang.c , "Malcolm McLean"
    <> wrote:

    >
    >"Kenny McCormack" <> wrote in message
    >>
    >> But here's the thing: I seriously doubt that, in the hosted world (at
    >> any rate), anything that can be written in "ISO C" (or whatever term you
    >> prefer) should be.


    Kenny's delusions are hard to understand.

    > I.e., anything that is that pure (such as your fuzzy
    >> logic program) could be written much more easily and readably in
    >> something like AWK.
    >>

    >I don't know AWK. If you've got time, try doing it. Seriously.


    I _do_ know awk, a little, and its not the beast for the job. awk with
    sed, grep, cat and tr, possibly. Yikes.

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
     
    Mark McIntyre, Oct 21, 2007
    #18
  19. James Kanze Guest

    On Oct 22, 12:38 am, Mark McIntyre <> wrote:
    > On Sun, 21 Oct 2007 18:39:13 +0100, in comp.lang.c , "Malcolm McLean"


    > <> wrote:


    > >"Kenny McCormack" <> wrote in message


    > >> But here's the thing: I seriously doubt that, in the hosted world (at
    > >> any rate), anything that can be written in "ISO C" (or whatever term you
    > >> prefer) should be.


    > Kenny's delusions are hard to understand.


    Yes. It depends on the application domain. In the domains I've
    worked in, it's probably true: I need sockets, and generally
    threads or a data base. But earlier in my career, I wrote
    compilers, and there's nothing in them which can't be readily
    expressed in ISO C; this is likely true for any other
    application which simply reads input, does some calculations or
    transformations, and writes it as output. I've got a lot of
    little helper programs which are written in pure ISO C++, and
    could almost certainly be written in ISO C with a bit more
    effort.

    > > I.e., anything that is that pure (such as your fuzzy
    > > logic program) could be written much more easily and readably in
    > > something like AWK.


    > >I don't know AWK. If you've got time, try doing it. Seriously.


    > I _do_ know awk, a little, and its not the beast for the job.
    > awk with sed, grep, cat and tr, possibly. Yikes.


    It depends on what the job it, but I agree that I usually end up
    using it within a shell script, if only to handle options.

    Where AWK really breaks down is when the code gets large enough
    that you want to maintain it in separate files. But I use it a
    lot for smaller things.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 22, 2007
    #19
  20. On Sat, 20 Oct 2007 20:45:58 -0000, wrote:
    > NOTE: I am really afraid of try-catch-throw. I have never been
    > able to understand it since it does not exist in C and I cant
    > really visualize the construct in terms of C.


    How try-catch-throw is actually implemented depends on the compiler,
    but one can explain it like this.

    Assume the following C++ code is written:

    #include <cstdio>

    // here's a sample object with a constructor and destructor
    // to demonstrate scope.
    class someobj
    {
    public:
    someobj() { std::puts("constructor"); }
    ~someobj() { std::puts("destructor"); }
    private:
    int x; // a dummy member variable
    };

    // A dummy type, it could be a typedef of int or whatever.
    // Just for the purpose of throwing an exception of this particular type.
    struct someexceptiontype
    {
    };

    void code_that_may_throw()
    {
    someobj obj; // instantiating someobj in this scope.

    if(false != true)
    {
    // some error situation happened, throw an exception.
    // someexceptiontype() instantiates an object of
    // "someexceptiontype" (without binding it into a variable),
    // and throw throws it.
    throw someexceptiontype();
    }

    std::puts("wow, false is true");
    }

    void some_intermediate_function()
    {
    std::puts("1");
    code_that_may_throw();
    std::puts("2");
    }

    int main()
    {
    try
    {
    some_intermediate_function();
    std::puts("executed without hitch");
    }
    catch(int e)
    {
    std::puts("caught an int");
    }
    catch(someexceptiontype e)
    {
    std::puts("caught someexceptiontype");
    }
    std::puts("end of main()");
    return 0;
    }

    The code above contains high-level concepts that approximately translate
    to the following lower-level concepts in C. It could be implemented
    differently, but the function is the same.

    #include <stdio.h>

    typedef struct someobj
    {
    int x;
    } someobj;

    void someobj__construct(someobj* this)
    {
    puts("constructor");
    if(__system_exception_ptr) goto __scope_end;
    __scope_end: ;
    }
    void someobj__destruct(someobj* this)
    {
    puts("destructor");
    if(__system_exception_ptr) goto __scope_end;
    __scope_end: ;
    }

    struct someexceptiontype
    {
    };

    /*** This global code is defined in some system library by the compiler */
    void* __system_exception_ptr = (void*)0;
    int __system_exception_type = 0;
    void __clear_exception()
    {
    __system_exception_type = 0;
    free(__system_exception_ptr);
    __system_exception_ptr = (void*)0;
    }
    /*** End of compiler library code */

    void code_that_may_throw(void)
    {
    someobj obj; // instantiating someobj in this scope.
    someobj__construct(&obj);
    if(__system_exception_ptr) goto __scope_end_before_obj;

    if(0 != 1)
    {
    someexceptiontype* e = (someexceptiontype*) malloc(sizeof(*e));
    __system_exception_ptr = e;
    __system_exception_type = 2;
    /* ^ a compiler-specific tag that identifies the exception type */
    goto __scope_end;
    }

    puts("wow, false is true");
    if(__system_exception_ptr) goto __scope_end;

    __scope_end: ;
    someobj__destruct(&obj);
    __scope_end_before_obj: ;
    }

    void some_intermediate_function(void)
    {
    puts("1");
    if(__system_exception_ptr) goto __scope_end;

    code_that_may_throw();
    if(__system_exception_ptr) goto __scope_end;

    puts("2");
    if(__system_exception_ptr) goto __scope_end;
    __scope_end: ;
    }

    int main(void)
    {
    some_intermediate_function();
    if(__system_exception_ptr) goto try_catch;
    puts("executed without hitch");
    if(__system_exception_ptr) goto __scope_end;
    goto past_catch;
    try_catch: ;
    switch(__system_exception_type)
    {
    case 1: /* example denoting int type */
    {
    __clear_exception();
    puts("caught an int");
    if(__system_exception_ptr) goto __scope_end;
    break;
    }
    case 2: /* example denoting someexceptiontype */
    {
    __clear_exception();
    puts("caught someexceptiontype");
    if(__system_exception_ptr) goto __scope_end;
    break;
    }
    default:
    goto __scope_end; /* still not caught */
    }
    past_catch: ;
    puts("end of main()");
    if(__system_exception_ptr) goto __scope_end;

    __scope_end: ;
    return 0;
    }

    Of course, for efficiency reasons there is no "if" test after every
    function return for exceptions (rather, execution may be transferred
    to a dedicated stack and scope unfolder when an exception happens),
    but this was the easiest way to explain what happens as regards for
    scopes and execution paths.
    Also, in the exception handler (catch {}), the exception object is
    not supposed to be deallocated until the end of the handler, but
    for simplicity I wrote the deallocation first.

    Followups set to comp.lang.c++ .

    --
    Joel Yliluoma - http://bisqwit.iki.fi/
    : comprehension = 1 / (2 ^ precision)
     
    Joel Yliluoma, Oct 23, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jon Maz
    Replies:
    7
    Views:
    4,347
    Jon Maz
    Oct 25, 2004
  2. Matt
    Replies:
    1
    Views:
    426
    Michael Rauscher
    Jun 12, 2004
  3. Chris Riesbeck

    try-catch-throw-finally

    Chris Riesbeck, Jan 19, 2007, in forum: Java
    Replies:
    3
    Views:
    1,060
    Chris Riesbeck
    Jan 22, 2007
  4. Replies:
    8
    Views:
    365
    Matteo
    Dec 5, 2005
  5. Replies:
    34
    Views:
    925
    Alf P. Steinbach
    Dec 2, 2007
Loading...

Share This Page