Should library error() calls have newlines?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Should library error() calls have newlines?

apjanke-floss
Hi, Octave maintainers,

Question about best practice for Octave package development: Should the
error() calls raised in package library functions end in newlines, so
the stack traces are suppressed, or not, so stack traces are displayed?
Trailing newline in error message strings controls stack trace display,
right?

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Should library error() calls have newlines?

Carnë Draug
On Thu, 2 May 2019 at 23:14, Andrew Janke <[hidden email]> wrote:
>
> Hi, Octave maintainers,
>
> Question about best practice for Octave package development: Should the
> error() calls raised in package library functions end in newlines, so
> the stack traces are suppressed, or not, so stack traces are displayed?
> Trailing newline in error message strings controls stack trace display,
> right?

Hi

Yes, a trailing newline will hide the stack trace.

I don't think there's any official stance on this though, but I would
say it's better to not hide it.  Let the whole stack trace be
displayed since hiding it makes debugging more difficult.

Reply | Threaded
Open this post in threaded view
|

Re: Should library error() calls have newlines?

apjanke-floss


On 5/5/19 12:18 PM, Carnë Draug wrote:

> On Thu, 2 May 2019 at 23:14, Andrew Janke <[hidden email]> wrote:
>>
>> Hi, Octave maintainers,
>>
>> Question about best practice for Octave package development: Should the
>> error() calls raised in package library functions end in newlines, so
>> the stack traces are suppressed, or not, so stack traces are displayed?
>> Trailing newline in error message strings controls stack trace display,
>> right?
>
> Hi
>
> Yes, a trailing newline will hide the stack trace.
>
> I don't think there's any official stance on this though, but I would
> say it's better to not hide it.  Let the whole stack trace be
> displayed since hiding it makes debugging more difficult.
>

Okay. I'll leave the stack traces displayed in my library code.

Thanks!

Cheers,
Andrew