> > procedure Main2 is
> >
> > type Color is (Red, Green);
> >
> > procedure Initialize (P : in out Color) is
> > begin
> > P := Green;
> > end;
> >
> > Var : Color;
> > Tar : Color range Red..Red;
> > Car : Color range Green..Green;
> >
> > begin
> >
> > Initialize(Var); -- GNAT 3.13p Does not raise exception
> > Initialize(Car); -- GNAT 3.13p Raises Constraint_Error
> > Initialize(Tar); -- GNAT 3.13p Raises Constraint_Error
> >
> > end;
> >
> Testing revealed no exceptions with pass-by-reference parameters. I need to
> understand when is this simply awful but unexceptional code, and when is it
> prone to exceptions. In particular, can the first call potentially raise
> exceptions on some other implementation? RM 3.2.2(12) suggests why a
> pass-by-copy parameter could raise an exception, but then why don't all
> three calls raise Constraint_Error?
Var and the parameter P both have the same subtype, so no range checking is
necessary.
> Are pass-by-reference parameters always
> immune to exceptions under these conditions?
Yes, since there is no copying.
> > The second category of problems is failure to assign a value to an "out"
> parameter. This is certainly a problem if the caller should try to use the
> result. However, exceptions can still arise even if the parameter is not
> used. Consider another example:
> >
> > procedure Main is
> >
> > type Color is (Red, Green);
> >
> > procedure Is_Broken (P : out Color) is
> > begin
> > null;
> > end;
> >
> > Var : Color;
> > Tar : Color range Red..Red;
> > Car : Color range Green..Green;
> >
> > begin
> >
> > Is_Broken(Var); -- Does not raise exception
> > Is_Broken(Tar); -- Does not raise exception
> > Is_Broken(Car); -- Raises Constraint_Error
> >
> > end;
> >
The same reason as above. That Tar does not raise an exception looks like a
coincidence to me. P must have been allocated at a place with the matching
internal representation (0 in this case).
> > The obvious solution is to always assign a value to the parameter, but this
> may not always be possible. For example, we have generic containers with
> methods that can return a component and a validity flag. If a component can
> not be returned, the container assigns nothing to the component parameter,
> and sets the validity parameter appropriately. Unfortunately, the
> containers have no formal nil object in there specification, and therefor
> cannot return a safe value. Again, to change a generic spec. can have
> significant ripple effect on other units.
If adding such a nil object is impossible, try the suppress pragmas. This should
solve the problem. (In any case, the clean and preferable solution would be the
nil object.)
> >
> Thanks in advance for your comments,
>
> - John Harbaugh
o _ _ _
--------- __o __o /\_ _ \\o (_)\__/o (_)
------- _`\<,_ _`\<,_ _>(_) (_)/<_ \_| \ _|/' \/
------ (_)/ (_) (_)/ (_) (_) (_) (_) (_)' _\o_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mein Radunfall
My bike accident
Christoph Grein
Mitglied von Ada-Deutschland
Member of Ada Germany
http:/www.ada-deutschland.de
http://home.T-Online.de/home/Christ-Usch.Grein
eMail: [log in to unmask]
|