<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 21, 2012 at 10:08 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="im">> This code is run in UI context, not server context, no? So the UI<br>
> should be checking the return of runCommand, seeing the error, and<br>
> aborting itself in whatever clean fashion is appropriate, rather than<br>
> the rather less so immediate sys.exit. Given that, I don't really see<br>
> how switching to bb.fatal here is buying us much. If we truly want<br>
> that error path to be different from that of other command failures,<br>
> then I would think that raising an appropriate exception (e.g.<br>
> something other than SystemExit) would be better.<br>
<br>
</div></div>The issue is that after this particular failure, any further runCommand<br>
is going to go badly wrong. "Timeout" would imply you could retry and in<br>
this case as described above, you cannot (which I agree sucks).<br>
<br>
So I think exiting in this case isn't such a bad thing although I'm less<br>
than happy about it. The only thing the UI could do is throw an error<br>
and exit.</blockquote></div><br>Agreed, but I think that's where the responsibility belongs. From the perspective of the UI, calling an API that exits you, for any reason, is pretty disgusting.<br>-- <br>Christopher Larson<br>
</div>