9:27 a.m.
Hello all,
I'm thinking that I'd like to get rid of option to do
set halt_on_error off
in gretl. But here's an opportunity to object if you are so
moved.
Brief reminder: halt_on error means that if an error is
encountered in running a script, execution of the script
stops. (When using gretlcli with the -b or --batch flag this
means that the program will exit.) This is the default
behavior, but setting "halt_on_error off" will (with something
less than 100% reliability?) cause script execution to
continue in face of errors -- unless gretl is currently
"compiling" a loop or function, in which case it stops
execution regardless of the halt_on error state.
This mechanism predates the "catch" modifier for commands --
and I would say that unlike "catch" it is pretty much useless
if not dangerous. The halt_on_error off-switch was originally
introduced as an aid to debugging gretl itself, but I haven't
found any use for it in that capacity in the last several
years. It's a complication we could do without.
Just to be clear: if I make the proposed change, it means that
in effect "halt_or_error" is always on. But you can still use
"catch" to test a given script command for an error condition
and continue on error if that seems appropriate.
For (minimal) backward compatibility we could make it so that
issuing the command "set halt_on_error off" does not itself
provoke an error, but just prints something like "Warning:
obsolete 'set' argument ignored".
Allin
10:46 a.m.
Sounds sensible to me.
PS
________________________________________
From: gretl-devel-bounces(a)lists.wfu.edu [gretl-devel-bounces(a)lists.wfu.edu] on behalf of
Allin Cottrell [cottrell(a)wfu.edu]
Sent: Saturday, July 06, 2013 9:27 AM
To: Gretl development
Subject: [Gretl-devel] scrap "halt_on_error" switch?
Hello all,
I'm thinking that I'd like to get rid of option to do
set halt_on_error off
in gretl. But here's an opportunity to object if you are so
moved.
Brief reminder: halt_on error means that if an error is
encountered in running a script, execution of the script
stops. (When using gretlcli with the -b or --batch flag this
means that the program will exit.) This is the default
behavior, but setting "halt_on_error off" will (with something
less than 100% reliability?) cause script execution to
continue in face of errors -- unless gretl is currently
"compiling" a loop or function, in which case it stops
execution regardless of the halt_on error state.
This mechanism predates the "catch" modifier for commands --
and I would say that unlike "catch" it is pretty much useless
if not dangerous. The halt_on_error off-switch was originally
introduced as an aid to debugging gretl itself, but I haven't
found any use for it in that capacity in the last several
years. It's a complication we could do without.
Just to be clear: if I make the proposed change, it means that
in effect "halt_or_error" is always on. But you can still use
"catch" to test a given script command for an error condition
and continue on error if that seems appropriate.
For (minimal) backward compatibility we could make it so that
issuing the command "set halt_on_error off" does not itself
provoke an error, but just prints something like "Warning:
obsolete 'set' argument ignored".
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
10:59 a.m.
On Sat, 6 Jul 2013, Allin Cottrell wrote:
Hello all,
I'm thinking that I'd like to get rid of option to do
set halt_on_error off
in gretl. But here's an opportunity to object if you are so
moved.
[...]
For (minimal) backward compatibility we could make it so that
issuing the command "set halt_on_error off" does not itself
provoke an error, but just prints something like "Warning:
obsolete 'set' argument ignored".
We could opt for a more gradual course of action:
* first, we reverse the default option to 'off' and we issue a
warning about "halt_on_error" being a deprecated setting whenever
appropriate
* in a few months, we scrap it.
Thoughts?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
11:30 a.m.
Em 6 de julho de 2013, Riccardo (Jack) Lucchetti escreveu:
On Sat, 6 Jul 2013, Allin Cottrell wrote:
Hello all,
>
> I'm thinking that I'd like to get rid of option to do
>
> set halt_on_error off
>
> in gretl. But here's an opportunity to object if you are so
> moved.
>
[...]
For (minimal) backward compatibility we could make it so that
> issuing the command "set halt_on_error off" does not itself
> provoke an error, but just prints something like "Warning:
> obsolete 'set' argument ignored".
>
We could opt for a more gradual course of action:
* first, we reverse the default option to 'off' and we issue a
warning about "halt_on_error" being a deprecated setting whenever
appropriate
* in a few months, we scrap it.
Thoughts?
I have some scripts where I use the "halt_on_error", but removing it seems
reasonable to me. I start to fix my scripts soon :-)
So I agree with Jack's suggestion.
Best regards,
Henrique Andrade*
*
11:47 a.m.
On Sat, 6 Jul 2013, Riccardo (Jack) Lucchetti wrote:
On Sat, 6 Jul 2013, Allin Cottrell wrote:
> Hello all,
>
> I'm thinking that I'd like to get rid of option to do
>
> set halt_on_error off
>
> in gretl. But here's an opportunity to object if you are so
> moved.
[...]
> For (minimal) backward compatibility we could make it so that
> issuing the command "set halt_on_error off" does not itself
> provoke an error, but just prints something like "Warning:
> obsolete 'set' argument ignored".
We could opt for a more gradual course of action:
* first, we reverse the default option to 'off' and we issue a
warning about "halt_on_error" being a deprecated setting whenever
appropriate
* in a few months, we scrap it.
Thoughts?
Um, no, reversing the default is not good. We want gretl to
halt on error unless "catch" is used -- which is the current
default.
To explain just a little more, the reason I don't like the
ability to turn halt_on_error off is that it's likely to give
rise to cascades of (increasingly incomprehensible) errors. A
script writer should figure out if any commands might fail for
good reason and, if so, use "catch" on them -- and not just
tell gretl to keep going regardless of how messed up things
are.
Allin
8:04 p.m.
On Sat, 6 Jul 2013, Allin Cottrell wrote:
Um, no, reversing the default is not good. We want gretl to halt on
error
unless "catch" is used -- which is the current default.
To explain just a little more, the reason I don't like the ability to turn
halt_on_error off is that it's likely to give rise to cascades of
(increasingly incomprehensible) errors. A script writer should figure out if
any commands might fail for good reason and, if so, use "catch" on them --
and not just tell gretl to keep going regardless of how messed up things are.
Uhm, point taken. Let's do as you say.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
8:48 a.m.
On Sun, 7 Jul 2013, Riccardo (Jack) Lucchetti wrote:
On Sat, 6 Jul 2013, Allin Cottrell wrote:
> Um, no, reversing the default is not good. We want gretl to halt on error
> unless "catch" is used -- which is the current default.
>
> To explain just a little more, the reason I don't like the ability to turn
> halt_on_error off is that it's likely to give rise to cascades of
> (increasingly incomprehensible) errors. A script writer should figure out
> if any commands might fail for good reason and, if so, use "catch" on them
> -- and not just tell gretl to keep going regardless of how messed up things
> are.
Uhm, point taken. Let's do as you say.
Actually, we could take the spirit of your suggestion (i.e.
gradualism) in this way:
1) In the next release, keep "set halt_on_error off" working as at
present but print something like
Warning: 'set halt_on_error off' is deprecated. Please use
'catch' to trap errors instead.
2) In the following release, remove it.
Allin
9:08 a.m.
On Sun, 7 Jul 2013, Allin Cottrell wrote:
On Sun, 7 Jul 2013, Riccardo (Jack) Lucchetti wrote:
> On Sat, 6 Jul 2013, Allin Cottrell wrote:
>
>> Um, no, reversing the default is not good. We want gretl to halt on error
>> unless "catch" is used -- which is the current default.
>>
>> To explain just a little more, the reason I don't like the ability to turn
>> halt_on_error off is that it's likely to give rise to cascades of
>> (increasingly incomprehensible) errors. A script writer should figure out
>> if any commands might fail for good reason and, if so, use "catch" on
them --
>> and not just tell gretl to keep going regardless of how messed up things
>> are.
>
> Uhm, point taken. Let's do as you say.
Actually, we could take the spirit of your suggestion (i.e. gradualism) in
this way:
1) In the next release, keep "set halt_on_error off" working as at present
but print something like
Warning: 'set halt_on_error off' is deprecated. Please use
'catch' to trap errors instead.
2) In the following release, remove it.
Deal!
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4151
days inactive
4152
days old
7 comments
4 participants
participants (4)
-
Allin Cottrell -
Henrique Andrade -
Riccardo (Jack) Lucchetti -
Summers, Peter