| |
| Posted by Steven Schveighoffer in reply to FeepingCreature | PermalinkReply |
|
Steven Schveighoffer
Posted in reply to FeepingCreature
| On 6/10/21 9:09 AM, FeepingCreature wrote:
> On Thursday, 10 June 2021 at 12:59:59 UTC, Steven Schveighoffer wrote:
>> On 6/10/21 8:07 AM, Kagamin wrote:
>>> On Wednesday, 9 June 2021 at 17:54:06 UTC, Timon Gehr wrote:
>>>> On 09.06.21 04:37, Walter Bright wrote:
>>>>>
>>>>> Allocating via the GC is in assert is just ridiculous, as the program is going to exit shortly anyway. There won't ever be a need to run a collection on it. Just malloc away and fuggeddabootet.
>>>>
>>>> AssertError is still *caught* /by the language/ on in contract inheritance.
>>>
>>> I'd say, lower assert failures in contracts to a different function, say, _d_contractFailed(), which can do a different thing, say, throw ContractError, and child contract can catch only this specific ContractError instead of any Error.
>>
>> What about asserts in functions called by the contract? I guess technically they are not part of the contract, just poor coding, but people may rely on those asserts in some cases.
>>
>
> All the more reason to throw `ContractError` instead of `AssertError`. Asserts in an unrelated function should not be caught as part of in-condition processing.
What about asserts in a related function? The foundation of programming with functions is that you can abstract common implementation into another function.
I could easily see someone making a helper function for lots of similar contracts.
It's an easy fix, just use to-be-implemented "contract_assert" which throws the right error, but the change would break code that exists. A deprecation might be painful (probably only triggered at runtime, so you might not catch all your cases).
-Steve
|