human-panic Tracking Issue: v2.0.0

This is a work-in-progress tracking issue for a 2.0 release of human-panic, set in motion because of #45

New Features

[x] Show message only to humans (#48 | PR: #50)
[x] Include original panic messages (#40 | PR: #43)
[ ] Include rustc version program was compiled with (#31)
[ ] Provide a way for tools to hook into panic reports (#30)
[ ] Provide a way for crash reporters to be called (#7)
[x] Split website and repository fields ( - | PR: #45)
[x] Update to Rust 2018 (#57)

Sep 26 '18 12:09 spacekookie

Something that might be useful to bikeshed for a 2.0 release is renaming setup_panic!(). It's seemed a bit odd to me given we don't quite setup a panic, but we setup a panic "handler" -- which seems quite different.

I'm thinking something like catch_panic!() or catch_unwind!(). The latter is in line with the standard library's naming scheme, which might make it easier to remember also.

Oct 03 '18 19:10 yoshuawuyts

How about install_human_panic!()?

The catch_ macros seem like they should "wrap" around some block to catch a panic within them. human-panic installs a global panic handler instead.

Oct 03 '18 19:10 mathstuf

@mathstuf with the 2018 module system macros should become a bit more easily traceable to their source. E.g.

import macro to file

use human_panic::install_human_panic;

fn main () {
  install_human_panic!();
}

use macro from import

use human_panic;

fn main () {
  human_panic::install_human_panic!();
}

It feels like in both cases the word human_panic is repeated a lot. I feel like having something without that name might make it a bit clearer.

The catch_ macros seem like they should "wrap" around some block to catch a panic within them. human-panic installs a global panic handler instead.

My personal preference would be to adopt human_panic::catch_unwind!();, which is similar to the stdlib's panic::catch_unwind!() method:

stdlib

fn main () {
  panic::catch_unwind(|| println!("hello!"));
}

human_panic

fn main () {
  human_panic::catch_unwind!();
}

There's probably some compat issues to be figured out, but I'm thinking the general idea should hold.

Oct 04 '18 10:10 yoshuawuyts

Yay a :bike: :house: !

Renaming the setup macro is definitely a good idea, although I'm not sure I'm happy with any of the suggestions so far :wink:

Repeating the term human_panic over and over is really not helpful whereas human_panic::catch_unwind!() looks too much like there is immediate action in the macro (or it's expecting to wrap some code – the way that human-panic v0.1 worked).

Instead what about something like this.

fn main() {
  human_panic::panic_handler!();

And it's still clear enough when the macro is directly in scope

use human_panic;
fn main() {
  panic_handler!()
}

It signals that some panic_handler action is performed, but I think is also clear enough that no immediate action is required. Plus it doesn't repeat human_panic twice :slightly_smiling_face: My 2-cents.

Oct 04 '18 11:10 spacekookie

@spacekookie yeah that seems reasonable! -- and yeah I guess we do have (our first?) bike shed on our hands :tada: wooh; that's not a bad problem to have!

Oct 04 '18 14:10 yoshuawuyts

:tada:

So #48 is now on master and if you look at the PR #50 we might want to release this only under a 2.0.0 because it can have severe impact on external systems. So that might be another good reason to make the next version a major bump.

Oct 04 '18 17:10 spacekookie

I just branched off fed6fda1a4827c00e9c43e580f2ea20ed9ee9b0b into it's own branch: 1.0.0-maintenance which is where all bug fixes for the 1.0.0 compatible versions can be accumulated.

This means that master is now breaking-changes land for v2.0.0!

Jun 14 '19 11:06 spacekookie

Should custom error messages (issue #54) be part of v2.0.0? It is the biggest thing holding me back from using human-panic.

Oct 02 '19 15:10 MichaelMcDonnell