Skip to content

Should DomainErrors accept arguments? #12152

Closed

Description

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    error handlingHandling of exceptions by Julia or the userneeds decisionA decision on this change is neededperformanceMust go faster

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions