"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:jhuaue$1rj5$1...@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.