Re: #12121's discussion for @tkelman.

Right now, DomainError doesn't take any arguments and will throw a MethodError if you try to pass an informative string. This is important because it's used in many performance critical math functions like sqrt, cf. @andreasnoack. @simonster chimed in to point out that

We could have DomainError{T<:Union(None,ByteString)} where DomainError() would be a DomainError{None}. I don't think that would be any more expensive when there's no string to be thrown. Would need some changes on the codegen side, though...

and @yuyichao mentioned the performance regression discussed at #11508. @simonster pointed out that

I'm not sure removing the GC frame would be enough. It would eliminate the additional cost for a DomainError with a string parameter in code that doesn't throw a DomainError, but you'd still have additional overhead if you actually throw a DomainError, which might matter.

What do we want to do going forward? Should we fix codegen, use #11508, or something else?