The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Feb 20 12:37:34 PST 2012


On 2/20/12 1:04 PM, foobar wrote:
> On Monday, 20 February 2012 at 17:47:35 UTC, Andrei Alexandrescu wrote:
>> On 2/20/12 11:32 AM, foobar wrote:
>>> On Monday, 20 February 2012 at 17:12:17 UTC, Andrei Alexandrescu wrote:
>>>> On 2/20/12 11:08 AM, Mafi wrote:
>>>>> If it's supposed to be simple factorization, then you should replace
>>>>> "throw r" with "return r". Then the name of that function doesn't make
>>>>> much sense anymore. But then you can better search for throw in user
>>>>> code and the stack traces aren't obfuscated anymore.
>>>>>
>>>>> throw createEx!AcmeException("....");
>>>>
>>>> I think that's a great idea, thanks.
>>>>
>>>> Andrei
>>>
>>> I fail to see the point in this. Why is the above better than
>>> throw AcmeException("....");
>>>
>>> If you want to avoid boilerplate code in the definition of
>>> AcmeException, this can be better accomplished with a mixin.
>>
>> The advantage is that e.g. the compiler can see that flow ends at
>> throw. Other languages have a "none" type that function may return to
>> signal they never end.
>>
>> Andrei
>
> I meant -
> what's the benefit of:
> throw createEx!AcmeException("....");
> vs.
> throw AcmeException("....");
>
> As far as I can see, the former has no benefits over the simpler latter
> option.

That's simply a workaround for non-inherited constructors - nothing more 
should be read into it.

Andrei




More information about the Digitalmars-d mailing list