Re: About String

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 08 Jun 2008 14:14:04 +0300, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Sun, 08 Jun 2008 09:47:30 +0300, Niklas Holsti wrote:
>> 
>>>The solution is just to add one more "begin..end" block, enclosing 
>>>the "declare .. begin .. end", and handle the exceptions in this 
>>>outer "begin..end" block. Or handle the exceptions in the 
>>>subprogram's "begin..end" block and nest the "declare..begin..end" 
>>>within the subprograms "begin..end".
>>>
>>>That said, I admit that I, too, have made this mistake once or 
>>>twice. But not lately.
>> 
>> If exceptions were contracted such, quite nasty, errors could be detected
>> at compile time.
> 
> Only if the programmer specifies the exception contracts separately 
> for the declarative parts and the statements. I don't remember any 
> such proposals.

I had this in mind:

function Boo raise Use_Error return String; -- That's not Ada
procedure Foo raise null;

procedure Foo is 
   X : String := Boo;
begin
   ...
exception
   when Use_Error => -- The handler is misplaced
      ...
end Foo;

This won't compile because Use_Error is not handled when propagates out of
Boo. But the contract of Foo promises no Use_Error.

>>>I wonder if it would be a good idea for Ada to allow an exception 
>>>handler also in the "declare" part, as follows:
>>>
>>>    -- NOT Ada!
>>>    declare <some variables>
>>>    exception <handle exceptions raised in the declarations>
>>>    begin <some statements>
>>>    exception <handle exceptions raised in the statements>
>>>    end;
>>>
>>>Of course, in this proposal the declaration-exception handler would 
>>>not have access to the declared variables.
>> 
>> But then, for regularity sake, you would need to add exception handling to
>> all declarative parts:
> 
> And why not?

Because that would make the margin between declarative and imperative more
fuzzy than it already is.

>> package A is
>>     <some declarations>
>> exception
>>     <handling elaboration problems of A, HOW?>  (:-))
>> end A;
> 
> It seems, from your smiley, that you feel that such a structure 
> would be somehow impossible. I don't see why; the exception handler 
> could execute any sort of non-erroneous code that could be executed 
> in any subprogram called as part of the declarations in package A. 
> For example, it could set some flag in another package to inform 
> the application that package A cannot be used because its 
> elaboration failed. If the application uses run-time elaboration 
> checks, it could even continue executing, as long as it does not 
> try to use anything in A. I admit that this might need an extended 
> form of run-time elaboration checks.

There are two models of exception handling:

1. Handle and continue
2. Wind-up then handle

The first was used by PL/1, I cannot tell if it still has it. The second is
Ada's model. It is sufficiently simpler (no upward closures etc) and also
more general, because it allows continuation without fixing.

Fixing a failed declaration would be the first model. I don't see how this
could be made, because the exception handler cannot see failed stuff. Which
is because it is still the second model... They don't live together.

For the second model, it is unclear what will be the status of failed A?
Say, B with-es A and A has failed. That means that B should also fail. But:

with A;
package B is
   ...
exception
   -- I still cannot handle A's failure here!
end B;

So we would need something like exception handlers in with!

with A
   package B
      ...
   end B;
exception
   -- OK, I can handle A's failure, but what happened with B?
end with A;

Nevertheless we still cannot do anything in order to fix B.

It seems that declarations could not be fixed in the second model.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de