Hallo,
maybe I’m missing something but I’m wondering why GetDoNotAllowVias() call returns true when called from a copper zone area.
By(t)e{s} weirdgyn
The value has no meaning for a copper zone, so it gets set to the default for a new keepout zone.
Ok. I think False should be a better default value anyway…
I suppose the same behaviour should be expected for GetDoNotAllowCopperPour() call?
Asking for properties that do not apply to copper zones will not provide you with useful or valid information when called using a copper zone. The call does not fail but it is up to the programmer to check whether the zone supports the parameter before using.
I wonder if a 3rd state (“error” or “unsupported”) should be the response for properties that aren’t supported on the queried board object. This would help programmers find their context errors faster. Or even write an error/unsupported trap routine to gracefully capture issues when a script written for a far future version of PCBNew is attempted to be run on our current or next version of PCBNew.
Not a bad idea. That said, there is some effort directed at the moment toward finalizing a specific Python API. No upgrades to the current SWIG’d version are going to be implemented until this is finished as the changes will be supplanted by the API.
or maybe an exception?
I’m not that familiar with Python. I’ve seen bugs causing exceptions and breaking programs. Are exceptions trappable so they can be handled within the program?
I’m not an expert with Python too but I’m sure it implements a try..catch mechanism like many other languages.
Of course, exceptions can be caught and processed in Python. The only reason there is perception that exceptions in python “break” programs is because python does the courtesy of showing these exceptions with a very nice but to an untrained eye gibberish looking stack trace.
Those same uncaught exceptions happen in a program written in any other language too but, for example C/C++ executable will (unless special care is taken against it) just crash and disappear with zero clue to what happened. So you don’t see a “scary” stack trace but it’s actually not useful to a dev who then has to try and reproduce the same issue on a special build with debug symbols under gdb.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.