Open Stack

It was in init code for a device driver, which (currently, as a short term PoC solution) reads a config file for settings of statically configured VPN devices. If there are no devices at all, it will report the issue and the agent will exit.  In the future, will be dynamically obtaining the device settings as needed, so this won’t be needed (and any failure will just fail the request and not exit the agent).

Regards,

PCM (Paul Michali)

MAIL …..…. pcm at cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On May 1, 2014, at 9:12 PM, Robert Collins <robertc at robertcollins.net> wrote:

> Raising SystemExit *or* calling sys.exit() are poor ideas: only outer
> layer code should do that. Plumbing should only be raising semantic,
> normally catchable exceptions IMO.
> 
> -Rob
> 
> On 2 May 2014 07:09, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:
>> On Thu, 2014-05-01 at 18:41 +0000, Paul Michali (pcm) wrote:
>>> So, I tried to reproduce, but I actually see the same results with
>>> both of these. However, they both show the issue I was hitting,
>>> namely, I got no information on where the failure was located:
>> 
>> So, this is pretty much by design.  A SystemExit extends BaseException,
>> rather than Exception.  The tests will catch Exception, but not
>> typically BaseException, as you generally want things like ^C to work
>> (raises a different BaseException).  So, your tests that might possibly
>> trigger a SystemExit (or sys.exit()) that you don't want to actually
>> exit from must either explicitly catch the SystemExit or—assuming the
>> code uses sys.exit()—must mock sys.exit() to inhibit the normal exit
>> behavior.
>> 
>> (Also, because SystemExit is the exception that is usually raised for a
>> normal exit condition, the traceback would not typically be printed, as
>> that could confuse users; no one expects a successfully executed script
>> to print a traceback, after all :)
>> --
>> Kevin L. Mitchell <kevin.mitchell at rackspace.com>
>> Rackspace
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev