From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,699cc914522aa7c4
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!news.glorb.com!uns-out.usenetserver.com!news.usenetserver.com!pc02.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Structured exception information
References: <eog0g5$2bn$1@cernne03.cern.ch> <u7ivnp09z.fsf@stephe-leake.org>
  <eoinoh$855$1@cernne03.cern.ch> <ud55drgzz.fsf@stephe-leake.org>
  <eolaen$b4h$1@cernne03.cern.ch> <ur6trwdov.fsf@stephe-leake.org>
  <eoqhhm$fjp$1@cernne03.cern.ch> <uac0dyap7.fsf@stephe-leake.org>
  <ep203u$o6s$1@cernne03.cern.ch> <u3b62dqj5.fsf@stephe-leake.org>
  <ep55f4$5c2$1@cernne03.cern.ch> <usldzbzu4.fsf@stephe-leake.org>
  <ep9r5i$uul$2@cernne03.cern.ch>
From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Fri, 26 Jan 2007 04:35:27 -0500
Message-ID: <ubqkmqgf4.fsf@stephe-leake.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt)
Cancel-Lock: sha1:FuNoXq0HM5A7QW5cRIsV5c0NXwY=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: 15e9245b9cb69759e00d425009
Xref: g2news2.google.com comp.lang.ada:8596
Date: 2007-01-26T04:35:27-05:00
List-Id: <comp.lang.ada>

Maciej Sobczak <no.spam@no.spam.com> writes:

> Stephen Leake wrote:
>
>> In my main project at work, it is much easier to format the messages
>> at the level where the relevant information is available.
>
> I prefer to have the relevant information available at the level where
> the messages are formatted.

As do I; that's what I said :).

> Looks like this is exactly the difference in our approaches. :-)

You have not explained _why_ you format the messages at a higher
level than necessary.

Here's an actual example from my current system (simplified). We have
an analog output module, that accepts user input and writes it to a
hardware register. There is a maximum voltage that the hardware
supports; if the user inputs a voltage higher than that, we want a
nice warning message.

So the code in the analog module looks something like:

procedure Write_Output
   (Module : in Module_Type; 
    Symbol : in Symbol_Access_Type)
is
   User_Volts : in Real_Type := Reals.Get (Symbol);
begin
   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;

end Write_Output;
  

This code is called from the user command parser (I'm using
OpenToken). There we have something like:

procedure Synthesize_Set
is
begin
    ...
    Set (Symbol, Token); --  Sets Symbol to user value
    Write_Output (Module, Symbol); -- dispatches to above
end Synthesize_Set;

One level up, in the main parsing loop, we have:

begin
   loop
      ...
      Parse; -- dispatches to Synthesize_*
   end loop;   
exception
when E : User_Error => 
    Put_Line (Ada.Exceptions.Get_Exception_Message (E));
end;

What would you change about this, and why?

You seem to be saying "pass User_Volts and Max_Volts up to the parser
loop, and let it format the message". But now the parser loop has to
understand the required information for _all_ possible errors in the
_entire_ system! For example, the digital potentiometer module has
_different_ limits that might be violated. That is _not_ information
hiding.

The way it's built now, the parser loop only has to deal with strings;
that's easy, and natural for a parser.

-- 
-- Stephe