Re: Exceptions: Are they GOTOs?

[msiso2@infos2.unilim.fr (OS2 User)]

	speaking about Reports vs GOTOs for Ada's exceptions,
	it is a false discussion.
GOTO
	Some of people say Exception = GOTO because they want to
        identify how the exception should work.

		------
		Instruction(s)
		Instruction >| exception |----.
		Instruction(s)                |
	       ------                         |
		 Handler <--------------------'
		   Selection & handling

	       ------                        (?)------->

	"Exceptions are GOTO" because it is like a jump to the
	exception handler (and even a dynamic jump throw several 
	levels).  In fact they identify the assumed exception 
        mechanisn and the exception.
	As say [Michel Gauthier]
        > The main difference between exception raise and goto is 
        >  that :
        >   - raising an exception is essentially declarative : 
        >     I assert that...
        >   - goto'ing (rather than 'going to') is imperative : 
        >     do this...	

	The goto must arise and the exception can hapend. 
	The GOTO must be in the same compilation unit, the 
	exception is made to be propagated.
	The Ada 95 exception have identity, occurence, message...
	Then I assert that GOTOs and exceptions are differents !


REPORT
        The report is a concept, it can be done using integer,boolean,
        message,... It signal that a software component cannot render 
	it service. To say I cannot render my service the first think 
	is to know 'what is the service' and how to make my report.
        Using report mut be done like this :

	Instruction =>Report
                 Report testing (?) handling (GOTO, Abort, ...)
        Instruction => ...

        The exception is just one implementation of the report signal.

	The advantages of Ada's exceptions are :
	o   the readability (two distinc parts for normal & handling)
        o   automating the report testing.
        o   the exception name (an user exception name should be explicit)
	o   the information transmited (with Ada 95)
	In Ada using control structures and Ada's exception all the exception 
	features (as described by goodenough 75) can be done :
	o   Abort     (Default)
        o   Retry     (With or not treatment)
	o   Continue  ( //     //    //     )
	   
	For these previous reasons, I assert than the exception is the 
	best way to implement report in Ada. But the exception is not
	the report. The report should be made specifying pre-, post-,
	and report-conditions to be usefull. 

OTHERS ( My own opignon)

	But exception is not the report is just it signal, like paper for
	news. Ada's exception is just a language tool to signal. The
	name "exception" help some of us to say exception must be used only
	for exceptionnal state. I am not agree with this !
	I think that Ada's exceptions can be use as a signal to break the 
	normal flow. Doing this, we _must_ be sure that using an exception
	is made in a safe way. 
	If you use only one file, why do you need to test the End_Of_File
	exception can make this for you ! The code is buggy only if the
	exception is _not_ expected. (If you use a offensive programming
	style, you must verify every pre-condition and for you you cannot
	expect this End_Of_File, your code can be buggy in this sense).
        One of the most popular example is the protected get.
	     PROTECTED_GET: loop
		  begin
	            Get( MY_DATA );
		    Skip_Line;
		    exit PROTECTED_GET;
                  exception 
                    when DATA_ERROR | CONTRAINT_ERROR =>
                        Skip_Line;
			Put_Line("Another try");
                    when others =>
			Put_Line(" Abnormal Error ");
			raise;
                  end;
             end loop; 
	I apreciate to know, how to verify that the user is going to
	enter a bad value ;-)
	the using exception dificulty is to identify each raise and
	to expect each of them. Guideline are usefull, they could be
	applied but we must know why to do this.
	The new Ada'95 exception mechanism is more complex than the previous 
	one, but it permit to handle exception in more complicated 
	situations. If we do not use it, we do not complexify the treatment ;
	but if we use it, It must be because we need it. 
	
	

--

					Christophe Faure

	 _______________________________________________________
	|	               *	   # #      ###    #    |
	|  Christophe FAURE     *         # # #  @  #  @  # @   |
	|  Tel :+33()55.45.72.32 *       #     #  ###    #      | 
	|  Fax :+33()55.45.73.15  *                             |
	|        		   *     Laboratoire M.S.I    	|
	|  e-mail : Faure@unilim.fr *    Universite de Limoges	|
	|			     *   F-87060 LIMOGES	|
	|_______________________________________________________|