teslaworksumn/raven-go — pull request #1 by tylrtrmbl (2013-12-29 00:50:17+00:00)
Title: Optionally-Synchronous Capture

All right @titanous, here's my (currently very rough) take on our discussion in cupcake/raven-go#4.

From you:

> My inclination is to keep it close to the existing model of having the Send method on transports be blocking until a final error can be returned. This allows the synchronicity to be managed by the Client rather than creating two options (sync/async) for each of two protocols (HTTP/UDP).

What I did:

I've added a `Capture` method, taking a `Packet` and some optional tags, that functions like `Send`/`Report` used to. It returns an error channel, so if we want to guarantee success and make a call synchronous we can.

I think it's best to keep our sentry-doc-spec'd APIs (`CaptureMessage`, `CapturePanic`, `CapturePanics`) remain async, since the spec doesn't care about success and doesn't provide a method for getting that status.

#### What else?

Oh, lots. So far, I haven't changed any tests, the `DropHandler` will make dropped Captures the user decides to wait on never arrive, and frankly there's some messy stuff in this first commit.

So, @titanous, let me know what you think of this direction, and I'll get to work cleaning this up and making changes.