Re: print_usage not triggering a backtrace

[John W. Eaton]

On 19-Jan-2010, Jaroslav Hajek wrote:

| On Mon, Jan 18, 2010 at 11:08 PM, John W. Eaton <address@hidden> wrote:
| > On 18-Jan-2010, Jaroslav Hajek wrote:
| >
| > | today I noticed that if a DLD or built-in function throws an error
| > | through print_usage, backtrace is not generated. Is this intentional?
| > | Or shall I attempt a fix?
| >
| > The reason this happens is that the character string that print_usage
| > sends to the error function ends in a newline character, and the error
| > function omits backtrace info if the character string it is given ends
| > in a newline character.
| >
| > I'm not sure what is best here, but I don't think it was intentional
| > to omit the backtrace info if the error is raised by print_usage.
| >
| > It is intentional that the error function omit backtrace info if its
| > argument ends in a newline character.
| >
| 
| OK. Exactly why is that? I suppose there is a good reason, but I don't
| see it right now.

This feature was added a long time ago, and is patterned after similar
behavior in Perl.

| So what about the following change?
| http://hg.savannah.gnu.org/hgweb/octave/rev/30817aa3889a
| 
| print_usage examines the dbstack to determine whether it's being
| called from top level. If not, it omits the additional help message
| and replaces the last newline by space, enabling backtrace again. It's
| a bit of a hack, admittedly.

Even if we change error so that it doesn't behave differently for
messages that end in newlines, we would probably still want to omit
the additional help message, or at least defer it until after the
traceback (that might be a bit harder to do).  Your solution seems OK
to me.

jwe