The Right Approach to Exceptions

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:jhuaue$1rj5$1 at digitalmars.com...
> 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.
>

The issue is that it's an ugly and unnecessary workaround. A couple 
alternates have been suggested.