On Wed, 03 Apr 2013 08:14:26 -0400
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed 03 Apr 2013 02:55:28 AM EDT, Peter Hatina wrote:
> Hi,
>
> On 04/01/2013 09:16 PM, Stephen Gallagher wrote:
>> Scriptons should follow standard Python recommendations for
>> return values and exceptions. We should make an attempt to
>> properly handle any expected exceptions (such as network errors)
>> at all levels (both in scriptons and OpenLMI)
>
> Wrt shell, I was not 100% sure, if to use exceptions or not. I
> know python uses them as often as possible, but from the user point
> of view, I wanted to avoid them (they can be turned on in the
> running shell), because of the stack trace etc, when an error
> occurs (are the lmishell users programmers?). Maybe I could drop
> the code, which "traps" the exceptions and packs them into classic
> C-return values, if we are OK with that.
>
That's a really interesting question. I was thinking that, since the
scriptons are python code, we should aim very closely at maintaining a
"pythonic" way of doing things. There's certainly an argument to be
made for having the scriptons behave a little more like bash scripts,
though.
I'd like to hear more opinions on this, ideally from people who might
eventually consume these scriptons. What would they like to see?
I understand scriptons to be the Python modules that may eventually be
wrapped by higher-level Python scripts. I don't think there is a way to not
to treat them as Python code. On the other hand the "higher-level" wrappers
should behave like shell commands since those would be standard executables
meant to be called from the standard shell scripts.
About the exceptions: I would rather see them turned on in the
non-interactive mode and caught and translated to error codes when using the
shell interactively by default. However we need to keep this behaviour
configurable (even runtime): we're targeting Python coders as well as
"ordinary admins" and these groups might have different preferences on how
the LMI Shell should behave.
Regards,
--
Tomáš Smetana
Platform Engineering, Red Hat