Design of bugsnag-2.0

[pbrisbin]

Looking over our open issues, and other discussions with @parsonsmatt has me considering a[nother] rewrite of this library.

There was a big shift in the deprecation of bugsnag-haskell in favor of the current bugsnag library solely due to wanting to re-use bugsnag-hs for the API types, rather than maintaining our own. This forced a number of other changes that, in isolation, aren't the best. After letting the dust settle and finding some upstream issues opened there going unanswered, I think it's appropriate to revisit that choice -- there's no value in offloading onto an upstream if they're not themselves actively maintained.

So, I think we should take back over and author our own Data.Bugsnag.* and release that as a new major version. I'd like to use this Issue to describe the choices I'd plan to make and get feedback before proceeding.

What I'm thinking:

• Data.Bugsnag.{Type}, each exposing a Bugsnag{Type} record, with bugsnag{Type}{Field} fields and {type}_{field} lenses

  This convention follows Amazonka, and seems generally reasonable. The lenses will be useful in authoring BeforeNotify functions. This will close Export Bugsnag prefixed type synonyms #78 and Lens-based interfaces #65.

• Data.Bugsnag.Exception will include bugsnagExceptionOriginalException, which will be SomeException

  This will close BeforeNotify API is less powerful than before #80. This is an open design point. I'm proposing we put it on Exception and not Event since the Bugsnag API itself models 1-event-to-N-exceptions, but a single exception per event is actually way more ergonomic, so I'm very open to being convinced otherwise (and may in fact change my mind myself).

• Due to the above, BeforeNotify can just become a newtype over Endo BugsnagEvent, with a derived <>

  This, combined with some HasBugsnagSettings reader results in cool stuff like:

  local (bugsnagSettingsL . settings_beforeNotify <>~ setSeverityWarning) $ do
    -- ...
  
  setSeverityWarning :: BeforeNotify
  setSeverityWarning = beforeNotify $ event_severity .~ WarningSeverity

• I will add Control.Monad.Bugsnag with (something like) MonadBugsnag(notify) with various DerivingVia newtypes.

  I know there are a few concrete suggestions for what this should look like, and it may be worth getting into. Perhaps this should be a new bugsnag-mtl package? A DerivignVia newtype for testing would solve Integration testing #47.

The addition of lenses and MonadBugsnag could (should?) actually come later anyway, since that won't incur a major version bump.

[pbrisbin]

WDYT @parsonsmatt @chris-martin ?

[parsonsmatt]

We actually have a bugsnag-mtl library at work that we're planning on open sourcing based on this library.

[parsonsmatt]

Data.Bugsnag.Exception will include bugsnagExceptionOriginalException, which will be SomeException

The ergonomics of "one exception per event" are pretty great. I do admit that I like that a lot. But apparently the reason for supporting a list of exceptions is to allow CausedBy exceptions - ie "This exception was thrown while handling this other exception", and you can record both. Haskell doesn't currently support this, but with the exception annotations proposal, it will. The proposed behavior is that if you catch an exception and rethrow an exception of a differing type, then it will attach an annotation like data WhileHandling = WhileHandling SomeException. In that world, this library could support the list approach by digging through the WhileHandling annotations.

I don't really like that design and plan on trying to argue against it, but that is the plan.

[pbrisbin]

OK, so it sounds like the following:

1. Our own Data.Bugsnag with records and lenses using Amazonka-like naming conventions
2. Don't make bugsnag-mtl yet, hope "the community" (e.g. Matt) will release it on top of our stuff after
3. It's a bit of an open question if original-exception should be a property of BugsnagEvent or BugsnagException

(1) will be a slog, so I think I'll get started on it while giving time to consider (3).