Conference turris::c_plus_plus

    Please correct me if I am wrong but after some research I think I have
    an answer.
    
    From Chapter 6  of the DEC C++ for OpenVMS  book:
    
       6.3  The /exceptions Qualifier
    
       This section describes the  /exceptions qualifier in detail.
    
    
       /exceptions[=[no]cleanup]
       /noexceptions (Default)
       Controls whether support for C++ exceptions is enabled or
       disabled. If you want C++ exceptions enabled, you must
       specify /exceptions , which uses the cleanup option by default.
    
       You specify the /exceptions qualifier to enable support for
       C++ exception handling. When the    /exceptions qualifier is
       in effect, the compiler generates code for throw expressions,
       try blocks, and catch statements. The compiler also gener-
       ates special code for main programs so that the   terminate()
       routine is called for unhandled exceptions.
    
    
    So, the routine provided by the customer was compiled to handle
    exceptions but did not provide any handlers.  The compiler provided a
    terminate () routine for all unhandled exceptions!  Ergo, the results
    seen are correct.

    Customer says "Yah, but..."
    
    

>Subject: 	Re: Problems with LIB$SIGNAL of info or warnings and C++
>exceptions.
>
>I agree that this is how it works, but from a VMS perspective I strongly
>disagree with this is how it SHOULD work.  lib$signal() of an information or
>warning status shouldn't rewind and terminate the application.
>
>I dislike C++ exceptions rewinding the stack before it executes your catch
>block (unlike VMS exceptions), but this is water under the bridge since the
>C++ committee has discussed this already:
>
>   See http://www.ses.com/~clarke/cpptips/resume_except.
>
>I know C++ doesn't have resumeable exceptions like VMS, but it would be
>really nice if we could use both in the same application.  But if you compile
>with /exceptions you just changed ALL your lib$signal() calls to terminate
>the application.  I think this problem should be reconsidered.
>

Did this customer read the section about VMS conditions and C++ exceptions
in the Using C++ Guide for OpenVMS?  Specificly the descriptions of 
using cxxl$set_condition() routine and using a 
catch (struct chf$signal_array &) handler?

Brian J.

    
Reply from customer:
    
    >re:  C++ 5.5 and exceptions
    >
    >Have you seen the section of Using C++ Guide for OpenVMS (version 5.5) 
    >concerning the descriptions on using the cxxl$set_condition() routine and the 
    >catch (struct chf$signal_array &) handler?
    
    Yes.  In fact I would argue with some of the quotes made there.
    For example:
    
    6.5  C++ Exceptions and Other OpenVMS Conditions
    
    Because C++ exceptions are implemented using the
    OpenVMS condition handling facility, C++ modules will
    work properly when they are part of a program that makes
    other uses of OpenVMS condition handling.
    
    I'm not sure I understand everything about the relations between
    VMS and C++ exceptions, but if you compile your main
    program with /EXCECPTION then all VMS signals will call terminate
    even when they are informational.  This seems wrong to me, and
    seems to violate the above paragraph.  For instance, given the below
    program:
    
    $ type t.cc
    #include <ssdef.h>
    #include <lib$routines.h>
    
    int main()
    {
    lib$signal(SS$_NOTHINGDONE);              // This is infomational
    return SS$_NORMAL;
    }
    
    Compiled, linked, and run you get:
    $ CXX T.CC
    $ CXXLINK T
    $ RUN T
    %SYSTEM-I-NOTHINGDONE, all the operations are not queued and not in progress
    
    But compiled, linked, and run with /EXC you get:
    $ CXX T.CC/EXC
    $ CXXLINK T
    $ RUN T
    %CXXL-F-TERMINATE, terminate() or unexpected() called
    %NONAME-F-NOMSG, Message number 0009804C
  image    module    routine             line      rel PC           abs PC
 T                                          0 0000000000020E38 0000000000030E38
 T                                          0 0000000000022114 0000000000032114
----- above condition handler called with exception 00000C43:
%SYSTEM-I-NOTHINGDONE, all the operations are not queued and not in progress
----- end of exception message
                                            0 FFFFFFFF81CE259C FFFFFFFF81CE259C
 T  T  main                              5563 00000000000000C8 00000000000300C8
 T  T  __main                               0 0000000000000064 0000000000030064
                                            0 FFFFFFFF81DF2914 FFFFFFFF81DF2914
    
    I think, the reason for this is that compiling main() with
    /EXC always adds an explicit:
    
    try
       {
	// code in main
       }
     catch(...)
       {
       terminate()
       }
    
    You can get rid of this problem by adding the following to T.CC.
    This makes VMS exceptions work as you would expect:
    
    $ type t.cc
    #include <ssdef.h>
    #include <lib$routines.h>
    
    static int my_handler(long signal_array[], long mechanism_array[])
    {
    return SS$_RESIGNAL;
    }
    
    int main()
    {
    lib$establish(my_handler);
    lib$signal(SS$_NOTHINGDONE);         // This is infomational
    return SS$_NORMAL;
    }
    
    This in effect, turns off C++ exception handling for the main as documented
    in section:  6.8  C++ Exceptions, lib$establish and vaxc$establish
    
    I think I understand how this all works by playing with it for several days,
    but I would like to know more about the C++ exception handler added to main
    and to each procedure by C++, and I wish the one added to main() would work
    differently with informational, warning, or error status codes to 
    lib$signal().




Thanks,

We're looking into this.

Thanks,
Coleen Phillimore
DEC C++ development