Support annotated-exception

[chris-martin]

Obviates https://github.com/freckle/megarepo/pull/31730 and some recent changes to freckle-app. When I roll back what I did to freckle-app I'll probably want to put an explicit lower bound on this version of bugsnag.

Also added some build infrastructure - a newer stack.yaml, and some nix stuff that helps me.

[pbrisbin]

Something like annotatedExceptionBeforeNotify that sets class/message/stacktrace is yet to come?

[chris-martin]

Maybe I should go ahead and throw it into this PR.

[chris-martin]

@pbrisbin I'm thinking we should go ahead and remove Network.Bugsnag.Exception.Parse altogether, wdyt? Would love to simplify by not trying to parse formatted traces at all. We can still display StringException traces by grabbing the call stack directly without parsing.

[pbrisbin]

I'm thinking we should go ahead and remove Network.Bugsnag.Exception.Parse altogether, wdyt? Would love to simplify by not trying to parse formatted traces at all

That's a good question, but I think it gets at your point about annotated-exceptions not being standardized as a callstack solution. Given that it's not, I don't think we can take away that existing support for trying to get whatever callstacks we can for users not using annotated-exception.

But I think we can evangelize, and ensure good support for annotated-exception and hope it sees broader adoption. Then, perhaps, we can make it essentially required for this library to offer good stacktraces, and we could drop that support for other methods.

[chris-martin]

Okay, I did rip that out already, but I can add it back as another fallback.

[chris-martin]

I think this could be ready to go.

However - While we're here, might as well also upstream MetaData from freckle-app?

eh, don't want to deal with adding an aeson dependency right now. Later.

[pbrisbin]

might as well also upstream MetaData from freckle-app?

Yeah, any part of it that's not Freckle-specific sounds like a decent fit.

I wonder, if we did the following all internally and automatically,

• Handle ex or AnnotatedException ex in updateFromOriginalException
• Had a default (global, "alwasy") BeforeNotify that handled AnnotatedException and updated errorClass, message, stacktrace and attached any other Annotations as metadata

Then do we ever need to mention AnnotatedException in our API? I.e. would updateFromOriginalAnnotatedException even ever be useful?

[chris-martin]

attached any other Annotations as metadata

For annotations other than CallStack and MetaData, just apply show, and throw the list into an "annotations" bugsnag tab?

[chris-martin]

The only reason to include annotated exceptions into the API is if the user has their own Annotation subtypes that they want to be able to report to bugsnag in some a special way. Since that's an "open" type that can hold anything, this seems conceivable.

[chris-martin]

Would be cool if freckle/blammo#30 were done :)

[chris-martin]

Going to also fourmolu this whole project because I don't know how to run brittany and it's falling over on the CPP

[pbrisbin]

For annotations other than CallStack and MetaData, just apply show, and throw the list into an "annotations" bugsnag tab?

I guess I defer to you. Would that be useful?

the user has their own Annotation subtypes that they want to be able to report to bugsnag in some a special way. Since that's an "open" type that can hold anything, this seems conceivable

Makes sense.

Would be cool if freckle/blammo#30 were done :)

Sure would.

[chris-martin]

I could imagine if annotated-exception caught on more in the ecosystem at large, you could get libraries relying heavily on annotations rather than the underlying exception to convey information you might want to see in bugsnag. But this is hypothetical. And perhaps that could be remedied outside of this library by catching and re-throwing with those annotations converted to MetaData. For now I think just supporting CallStack and MetaData annotations makes sense until there is a use case to drive the design.