December 12, 2016 Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Here it is: https://github.com/dlang/druntime/pull/1710 It relieves code that uses assert from needing the GC. I think all Errors should be singletons - multiple objects in that hierarchy arguably make no sense. But of course there are many situations out there. If this breaks your code, please holler. Andrei |
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>
> But of course there are many situations out there.
Wouldn't it break chained assertion errors?
|
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
> I think all Errors should be singletons - multiple objects in that hierarchy arguably make no sense.
With that logic, why does Throwable have the field "next"?
|
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to safety0ff | On Monday, 12 December 2016 at 16:35:22 UTC, safety0ff wrote:
> Wouldn't it break chained assertion errors?
An Error is unrecoverable anyway, if such a case arises it can always just abort the program immediately.
|
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 12/12/16 17:51, Andrei Alexandrescu wrote:
> Here it is:
>
> https://github.com/dlang/druntime/pull/1710
>
> It relieves code that uses assert from needing the GC. I think all
> Errors should be singletons - multiple objects in that hierarchy
> arguably make no sense. But of course there are many situations out
> there. If this breaks your code, please holler.
>
>
> Andrei
As you may know, Weka has a huge GC aversion. Despite that fact, I fail to see the improvement such a change would bring. The only situation under which using the GC is not harmful is when the entire process is about to go kaboom anyways.
Now, if you'd make regular Exceptions GC free....
Shachar
|
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 12/12/16 17:51, Andrei Alexandrescu wrote:
> Here it is:
>
> https://github.com/dlang/druntime/pull/1710
>
> It relieves code that uses assert from needing the GC. I think all
> Errors should be singletons - multiple objects in that hierarchy
> arguably make no sense. But of course there are many situations out
> there. If this breaks your code, please holler.
>
>
> Andrei
I'll just add that we're not using AssertError anyways. We found that the various scope(failure) and scope(exit) that run in such cases significantly detract from the ability to debug what actually happened.
Our assert immediately terminates the process.
Shachar
|
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to safety0ff | On 12/12/2016 11:35 AM, safety0ff wrote:
> On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>>
>> But of course there are many situations out there.
>
> Wouldn't it break chained assertion errors?
Once a type in Error's cone gets thrown there is no guarantee of unwinding, hence no guarantee of chaining. -- Andrei
|
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to Guillaume Boucher | On 12/12/2016 12:43 PM, Guillaume Boucher wrote:
> On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>> I think all Errors should be singletons - multiple objects in that
>> hierarchy arguably make no sense.
>
> With that logic, why does Throwable have the field "next"?
Probably only Exception should. -- Andrei
|
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shachar Shemesh | On 12/12/2016 02:54 PM, Shachar Shemesh wrote: > On 12/12/16 17:51, Andrei Alexandrescu wrote: >> Here it is: >> >> https://github.com/dlang/druntime/pull/1710 >> >> It relieves code that uses assert from needing the GC. I think all >> Errors should be singletons - multiple objects in that hierarchy >> arguably make no sense. But of course there are many situations out >> there. If this breaks your code, please holler. >> >> >> Andrei > > As you may know, Weka has a huge GC aversion. Despite that fact, I fail > to see the improvement such a change would bring. Why am I not surprised :o). > The only situation > under which using the GC is not harmful is when the entire process is > about to go kaboom anyways. You get to use assert without needing to link in the GC. > Now, if you'd make regular Exceptions GC free.... That will come too. Andrei |
December 12, 2016 Re: Making AssertError a singleton | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 12/12/16 12:59 PM, Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/12/2016 11:35 AM, safety0ff wrote:
>> On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>>>
>>> But of course there are many situations out there.
>>
>> Wouldn't it break chained assertion errors?
>
> Once a type in Error's cone gets thrown there is no guarantee of unwinding, hence no guarantee of
> chaining. -- Andrei
For this to have much meaning, at some-point druntime (for all the various compilers) is going to need to be changed to not unwind. It does, and has all the effects that come from that. What actually happens tends to trump what the documentation claims it's allowed to not do. Of course, then you'll find the fun of all the tests (and probably code) that catch AssertError.
|
Copyright © 1999-2021 by the D Language Foundation