This is quite a funny case. I guess it's not an error per se, and it's probably usually true that it would not be a surprise to the thrower that the span would be treated as exiting successfully in this situation...

That said, it seems like you'd generally be able to throw ExitSuccess or other "positive exceptions" from outside of the inSpan'' block. If we went the direction of baking in gracefully treating some thrown exceptions as successes, I'd probably like to see SpanArguments provide a more generalized mechanism–

An example of a case that we currently deal with at Mercury is that we have some 3rd-party systems that we use http-client to long-poll. The long-polling connections always time out at 60 seconds, so they show up as errors due to receiving some kind of timeout exception, but actually that's working as expected. What if we added something along the lines of:

data SpanExceptionDecision 
  = Unexpected (HashMap Text Attribute)
  | Expected (HashMap Text Attribute)

data SpanArguments = SpanArguments
  { ...
  , diagnoseException :: SomeException -> SpanExceptionDecision
  }

Yeah, it has big Error: Program completed successfully vibes

diagnoseException on SpanArguments is a good idea - but it does seem a bit worrying to me that you can do, say,

inSpan "asdf" defaultSpanArguments { diagnoseException = blah } do
  inSpan "qwer" defaultSpanArguments do
    throwSomethingDope

Then the inner span is reported with an error, but the outer one isn't. Maybe that's totally fine and the behavior for exception diagnosis shouldn't be inherited. Idk on the exact semantics.