Re: About String

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Dmitry A. Kazakov wrote:
> 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:

>>> [ About the fact that exceptions raised in a declarative
 >>>   part cannot be handled by the handler in the following
>>>   handled_sequence_of_statements, and it is an error
 >>>   to try. ]
>>>
>>>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 agree that exception contracts would work in this example. Ok, 
exception contracts would reveal some -- perhaps most -- of these 
errors at compile time, but not all.

>>>>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.

That is a philosophical reason, and I might even agree with it, but 
it is not a technical problem.

>>>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.

Yes. And I like the Ada approach better.

> 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.

I agree that an exception handler in a package declaration could 
not do anything to recover or repair the failed elaboration (unless 
the package declaration is nested in a subprogram, of course, so 
that the subprogram may be called again with better success).

But such an exception handler could still do something useful, for 
example by logging the problem, invoking some "safing" actions, 
etc., as long as these actions do not depend on the package that 
failed its elaboration.

> For the second model, it is unclear what will be the status of failed A?

The Ada run-time semantics already has a concept of something (eg. 
a subprogram) that is not "yet" elaborated, and can potentially be 
invoked before it is elaborated, triggering a run-time elaboration 
check and possible raising of Program_Error. A package with a 
failed elaboration could be in a similar state.

Note again that I'm not proposing that exception handlers should be 
allowed in package declarations, just exploring the theoretical 
possibility.

> Say, B with-es A and A has failed. That means that B should also fail.

Sure, why not. If A's elaboration fails, all subsystems depending 
on A should be unusable. I think some distinction between failing 
package declarations and failing package bodies could be used to 
contain the spreading of the failure.

>    -- I still cannot handle A's failure here!

I agree that an application could not *recover* from failures in 
package elaboration. But the application could possibly fail more 
gracefully, perhaps even continue operating in a degraded mode.

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

Only in the (unusual) case where a package is nested in a callable 
entity. If the package elaboration fails on one call, the exception 
handlers could take some action that makes the next call succeed 
better. In theory.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .