Open pbrisbin opened 8 months ago
WDYT @parsonsmatt @chris-martin ?
We actually have a bugsnag-mtl
library at work that we're planning on open sourcing based on this library.
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.
OK, so it sounds like the following:
Data.Bugsnag
with records and lenses using Amazonka-like naming conventionsbugsnag-mtl
yet, hope "the community" (e.g. Matt) will release it on top of our stuff afterBugsnagEvent
or BugsnagException
(1) will be a slog, so I think I'll get started on it while giving time to consider (3).
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 currentbugsnag
library solely due to wanting to re-usebugsnag-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 aBugsnag{Type}
record, withbugsnag{Type}{Field}
fields and{type}_{field}
lensesThis convention follows Amazonka, and seems generally reasonable. The lenses will be useful in authoring
BeforeNotify
functions. This will close #78 and #65.Data.Bugsnag.Exception
will includebugsnagExceptionOriginalException
, which will beSomeException
This will close #80. This is an open design point. I'm proposing we put it on
Exception
and notEvent
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 anewtype
overEndo BugsnagEvent
, with a derived<>
This, combined with some
HasBugsnagSettings
reader results in cool stuff like:I will add
Control.Monad.Bugsnag
with (something like)MonadBugsnag(notify)
with variousDerivingVia
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? ADerivignVia
newtype for testing would solve #47.The addition of lenses and
MonadBugsnag
could (should?) actually come later anyway, since that won't incur a major version bump.