From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 2F7591F4B4;
	Thu, 17 Dec 2020 23:25:53 +0000 (UTC)
Date: Thu, 17 Dec 2020 23:25:53 +0000
From: Eric Wong <e@80x24.org>
To: meta@public-inbox.org
Subject: thoughts on failure messages in UI/UX...
Message-ID: <20201217232553.GA14131@dcvr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
List-Id: <meta.public-inbox.org>

Most command-line programs in AOT compiled languages won't
emit line numbers on failures.

On the flip side, languages like Python/Ruby spew huge
stack traces on failures that most users probably glaze over
(I know I do :P)

Perl die("no trailing newline") will emit the line number it's
called from, but die("newline exists\n") omits the line number.

I'm thinking we should favor showing the line number since
anybody running our code already has the source available
(this is why I prefer scripting languages).

That would allow users to open that code in $EDITOR and poke
around.  If they need to, they can replace the die() call with
Carp::confess/longmess to dump stack.