Re: Structured exception information

[Georg Bauhaus <bauhaus@futureapps.de>]

On Fri, 2007-01-26 at 04:35 -0500, Stephen Leake wrote:

> So the code in the analog module looks something like:
> 
...
>    if User_Volts > Max_Volts then
>       raise User_Error with 
>         Real_Type'image (User_Volts) & 
>         " greater than " & 
>         Real_Type'image (Max_Volts);
>    else
>       Write_Hardware (Module.Hardware_Device, To_Counts (User_Volts));
>    end if;

I'd prefer something like

procedure Write_Output
   (Module : in Module_Type;
    Symbol : in Symbol_Access_Type)
is
   User_Volts : constant Real_Type := Reals.Get (Symbol);
begin
   if User_Volts > Max_Volts then
      View.Set_Error((Off_Error with
                          Condition => Greater_Than,
                          Required => Max_Volts,
                          Given => User_Volts));
      raise User_Error;
   else
      Write_Hardware (Module.Hardware_Device, To_Counts (User_Volts));
   end if;

end Write_Output;

And then

exception
  when E : User_Error => 
    View.Show_Error;
      -- Uses the interface of the progenitors of Off_Error,
      -- for the object entered using View.Set_Error.
      -- If we had exception types, this could be
      -- much simpler, just View.Show_Error(E).
    View.Print(Ada.Exceptions.Get_Exception_Message (E));
end;


> What would you change about this, and why?

Absent exception types, making exception info propagation
explicit will add some advantages, in addition to not being
implicit as in exception strings:

- message information isn't dependent on arbitrary strings in the
  implementation of Write_Output. You'd need to recompile a
  *validation* procedure when the *message* should change even
  though the validation didn't change. From this viewpoint
  Write_Output mixes two separate concerns: input checking
  and UI message construction.

- Off_Error is derived from an abstract data type describing
  failure information. A user of this type can choose a
  suitable message constructed from the information.
  This is both *MVC* and also *decoupling*: The procedure Write_Output
  can be used unchanged even when error messages are to be
  displayed using Wide_String, a pair of LEDs or a Spanish
  character set.
  The construction of a message that meets the UI criteria (the
  parser loop with prompt in this case) becomes the job of the
  a View package that matches the display.

- the program points the reader to the software types and
  modules involved in propagating error information by
  naming the package and type at both ends (View in this case).
  A change in the implementation of View won't necessitate
  a recompilation of Write_Output, unlike using
  raise ... with ... for message construction.

- Any useful information that compilers add for an exception
  occurrence will not be touched.