Ticket #10283 discusses using `-fdefer-type-errors` to test that certain programs do not type check. In practice, this involves evaluating certain expressions to WHNF at run-time can checking whether they trigger an exception. Currently, it seems the exception to catch is an `ErrorCall` exception. It would be nice if we could very specifically catch type errors though. It's entirely possible that a critical test case that I want to be a type error mistakenly type-checks and then calls `error`. In such a situation, it's hard to distinguish such a true run-time error from a deferred type error. It would be much nicer if something like `TypeError` would be thrown instead of `ErrorCall`. Yes, it's currently possible to look at the text of the `ErrorCall` and check for certain text fragments in there, but that sounds extremely fragile to me. <details><summary>Trac metadata</summary> | Trac field | Value | | ---------------------- | -------------- | | Version | 7.10.1 | | Type | FeatureRequest | | TypeOfFailure | OtherFailure | | Priority | normal | | Resolution | Unresolved | | Component | Compiler | | Test case | | | Differential revisions | | | BlockedBy | | | Related | | | Blocking | | | CC | | | Operating system | | | Architecture | | </details> <!-- {"blocked_by":[],"summary":"Create a dedicated `TypeError` exception type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Ticket #10283 discusses using `-fdefer-type-errors` to test that certain programs do not type check.\r\n\r\nIn practice, this involves evaluating certain expressions to WHNF at run-time can checking whether they trigger an exception. Currently, it seems the exception to catch is an `ErrorCall` exception. It would be nice if we could very specifically catch type errors though. It's entirely possible that a critical test case that I want to be a type error mistakenly type-checks and then calls `error`. In such a situation, it's hard to distinguish such a true run-time error from a deferred type error. It would be much nicer if something like `TypeError` would be thrown instead of `ErrorCall`.\r\n\r\nYes, it's currently possible to look at the text of the `ErrorCall` and check for certain text fragments in there, but that sounds extremely fragile to me.","type_of_failure":"OtherFailure","blocking":[]} -->