X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 2 Feb 2021 22:40:16 +0100 (CET)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] recursive subsheet issue
In-Reply-To: <0cc19ac4-217d-0897-52db-8b6fdcbbd975@epilitimus.com>
Message-ID: <alpine.DEB.2.21.2102022220190.4264@nimbus>
References: <d3f9a609-d761-8646-8f4f-0f3fb3fa6b33 AT epilitimus DOT com> <alpine DOT DEB DOT 2 DOT 21 DOT 2102021301260 DOT 1295 AT nimbus> <0cc19ac4-217d-0897-52db-8b6fdcbbd975 AT epilitimus DOT com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2145332747-1612302016=:4264"
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-2145332747-1612302016=:4264
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 2 Feb 2021, Glenn (glimrick AT epilitimus DOT com) [via 
geda-user AT delorie DOT com] wrote:
> Okay, I'll let you know when it is ready. Anything special about
> exception objects in python?
> Thinking is if recursion is detected, throw an exception which is caught
> at the  xorn.netlist.innermain level, report the error, and terminate.

I try to keep using exceptions at a minimum.  In particular, an input 
error should not terminate netlist generation just like a compiler error 
doesn't terminate compilation.

Instead, the error should be reported by calling the "error" method on the 
offending pin, component, or schematic, or, if none of these apply, on the 
netlist object.  This prints the error message along with the filename and 
object coordinates and sets the "failed" flag so no netlist is emitted.

For warnings, there is a similar "warn" function which doesn't set the 
failure flag.  The convention is that everything which may result in an 
invalid netlist should be an error, and everything that indicates that the 
resulting netlist will most probably not be what the user intended should 
be a warning.

After reporting the error, netlist generation continues.  Instead of the 
invalid input, the next-valid thing should be assumed; in this case, this 
would probably mean ignoring the offending instantiation.  While there may 
be follow-up errors, seeing the next errors in advance may spare the user 
some unnecessary round-trips.

> For the xspice backend, which I have finally started to get back to, I
> decided it would be nice in the header of the output to provide a
> listing of the hierarchy from which the netlist was generated in case
> you don't get the output you are expecting re: refdes etc.

Sounds useful.  If I recall correctly, this information is contained in 
the netlist object which is passed to the backend.

Roland

--8323329-2145332747-1612302016=:4264--