Avoid same error if other line than first change

[shingara]

Only the first line of backtrace was use to mark error like same. Avoid
this behavior because some language ( like python ) change only last
line of backtrace

See mailing https://groups.google.com/d/msg/errbit/JuIGnN289ps/FWWF6_6qDR8J

[coveralls]

Coverage increased (+0.45%) when pulling 28a7ff2 on shingara:bugs/not_same_if_change_last_backtrace_line into 0e90eba on errbit:master.

[senny]

Thanks, I'll run this PR to see the difference in the upcoming days.

/cc @jone

[shingara]

@senny @jone This fix works fine to you ?

[senny]

@shingara sorry for the delay, I've just deployed the branch and it does indeed split the errors up where previously we would have gotten a single group. As this change could lead to many more groups I'd like to monitor it for some time running with the patch and see how the grouping turns out. Is that alright for you? I'll provide feedback in the upcoming week.

[shingara]

Ok, thanks. I waiting your feedback to merge this patch and release the 0.2.1 errbit version.

[senny]

@shingara the patch works good and the grouping is much more useful than before. Thank you.

[PikachuEXE]

How should I produce custom errors if I want to use this?
Since I got lots of custom error groups but they were group together

I think the behaviour of "Fingerprint" needs some documentation

[tamaloa]

Same here.
Updated to 0-2-stable a few days ago and suddenly got an application with several thousand new exceptions (would have been a single exception group with several thousand occurrences before)! May be a weird application dependent bug (stacktrace length is excessive with several hundred identical lines) but a better documentation would help :)

The exceptions all seemed to have occured in delayed_job 3.0.5 in combination with delayed-plugins-airbrake-1.0.0

[shingara]

Ok, I really need release a errbit 0.2.1 version with this fix so.

[tamaloa]

Yes - actually we patched the code locally to restore old behaviour which is of course not ideal :(

I suppose a lot of people , as we do, use CustomExceptions to catch all exceptions in a certain piece of code. There should be the possibility to see these exceptions grouped. It would be great if errbit continued supporting this behaviour either via a global config option or a per application behaviour.

Typical example :)

begin
  response = HTTParty.get(self.url)
rescue Exception => e
  raise CustomWebRequestSomehowFailedException.new(e)
end

would have been grouped nicely before (while still providing the different error classes on the overview as percentage)