Custom error message

[naturallymitchell]

Would it be possible to set a custom error message?

Perhaps a project could have a text file or config file that it passes as a string to human-panic's sourcing of its text.

This would also fix #7 (comment).

[tisonkun]

Here is a similar scenario I met in GreptimeTeam/greptimedb#1165 (comment).

But given that the Metadata interface is public, we can hack into setup_panic for expanding it manually + write our own print_msg.

The tricky part here is how to customize. But accepting a manner config struct to manipulate may be possible.

I can volunteer to make a demo, but it somehow changes the crate's taste or manner, so I don't want to just dive into it unless the maintainers agree on it and help on reviewing.

cc @epage @spacekookie

[epage]

If people have ideas on how to improve the default message, I would love for us to focus on that. However, I recognize that there may be cases for improving it. I'd be interested in looking at proposals for how to be customizing the message. This doesn't have to be code. It can be an API with a description on how to affects the text.

[alejandrodnm]

The use case I have right now is that I want to specify more ways for users to report an issue:

- Open a support request from the Timescale console:

  https://console.cloud.timescale.com/dashboard/support

- Open a support request by email to [email protected]

- Take your issue to the #migration channel in the community slack, where
  the developers will help:

  https://timescaledb.slack.com/archives/C04PT0Q74EA

I ended up doing it by:

const SUPPORT_MSG: &str = r"https://timescale.com

To submit the crash report:

- Open a support request from the Timescale console:

  https://console.cloud.timescale.com/dashboard/support

- Open a support request by email to [email protected]

- Take your issue to the #migration channel in the community slack, where
  the developers will help:

  https://timescaledb.slack.com/archives/C04PT0Q74EA";

let meta = Metadata {
                version: env!("CARGO_PKG_VERSION").into(),
                name: env!("CARGO_PKG_NAME").into(),
                authors: "".into(),
                homepage: SUPPORT_MSG.into(),
};

[tisonkun]

I propose a patch - #122

There can be a lot of things to be improved, but let's first discuss if the direction is desired.

That is - introduce a Writer/Printer trait for customizing panic message; may or may not we can extend metadata struct later.

The proposed change is backward compatible.

[epage]

If the focus is on additional links, what if we provided ways for people to extend specifically that?

I'd like for us to share what we can so if things are improved for one, they are improved for all.

[tisonkun]

If the focus is on additional links, what if we provided ways for people to extend specifically that?

I'd like for us to share what we can so if things are improved for one, they are improved for all.

LGTM. Send #133 for review.

[terakilobyte]

We don't want anyone sending an email, so I propose the ability to specify the report section. I'd be happy to submit a PR if it would be acceptable and helpful.

[epage]

Likely "email" should just be removed

[terakilobyte]

I believe the entire sentence beginning with "Submit an issue or email..." could safely be removed and handled in the support section.

[epage]

We need the link to the file and I think its important to call out that the support the file should be used in the support method. As people likely haven't written their support methods to mention it, leaving it solely to that would be a regression for these users and I'd prefer to use a breaking change for such a regression.

[terakilobyte]

I absolutely agree the file should be linked. I've submitted a draft PR to more clearly capture what I was thinking.