Improve argument reporting

[joshuap]

Honeybadger now supports sending arguments, however the cases where the arguments are actually available seem limited; see this comment by @sorentwo.

We may be able to provide arguments more often by studying how Elixir/iex display the arguments in printed stack traces.

[TraceyOnim]

I have found out, arguments are available when a FunctionClauseError is reported. Here is the explanation.

With that, I have also found out that, the stack trace is been parsed at notice.ex line 57. Hence for the limited cases like FunctionClauseError, the arguments are not available for the final output. There is an existing PR for the fix

[joshuap]

@TraceyOnim nice!

So with #373 merged, what should the documentation say about filter_args? It still only works for FunctionClauseError, right? If that's the case, we should update the README with that information to make it clear how it works. Do you want to work on that?

Also, I added a changelog entry for #373: 44c15cf

[joshuap]

Another question: do you think it's possible to display args for other types of exceptions with some additional research/work in the future? Or should I close this issue after the documentation is updated?

[TraceyOnim]

@TraceyOnim nice!

So with #373 merged, what should the documentation say about filter_args? It still only works for FunctionClauseError, right? If that's the case, we should update the README with that information to make it clear how it works. Do you want to work on that?

Also, I added a changelog entry for #373: 44c15cf

From the research, I can say filter_args only works with FunctionClauseError.
Yes , I can work on the documentation

I have checked the changelog 44c15cf. Arguments are shown when filter_args is set to false, right? The changelog states true

[joshuap]

I have checked the changelog 44c15cf. Arguments are shown when filter_args is set to false, right? The changelog states true

Ah yeah, good catch! I'll fix it.

[TraceyOnim]

Another question: do you think it's possible to display args for other types of exceptions with some additional research/work in the future? Or should I close this issue after the documentation is updated?

Lemme do some additional research on this first before closing. Just in case I might miss something

[joshuap]

@sorentwo I've been thinking, would it make sense to default to filter_args = false in the next major release, so that args are reported w/ FunctionClauseError by default?

[TraceyOnim]

@sorentwo I've been thinking, would it make sense to default to filter_args = false in the next major release, so that args are reported w/ FunctionClauseError by default?

Great idea, I second this

[sorentwo]

@joshuap That would improve the experience for most people and isn't a breaking change. I'm in favor 👍

[joshuap]

@sorentwo I've been thinking, would it make sense to default to filter_args = false in the next major release, so that args are reported w/ FunctionClauseError by default?

Great idea, I second this

@TraceyOnim great, want to submit a PR for that? If the two of you are good with a minor release instead of major (since it's not breaking), I'm good with that.

[TraceyOnim]

@sorentwo I've been thinking, would it make sense to default to filter_args = false in the next major release, so that args are reported w/ FunctionClauseError by default?

Great idea, I second this

@TraceyOnim great, want to submit a PR for that? If the two of you are good with a minor release instead of major (since it's not breaking), I'm good with that.

Sure, I can submit the PR

[joshuap]

Confirmed that args are reported properly for FunctionClauseError in v0.16.4!

For future reference, here's a simple way to cause a FunctionClauseError:

Enum.drop([1, 2, 3], 0.0)