DIP33: A standard exception hierarchy

Dmitry Olshansky dmitry.olsh at gmail.com
Tue Apr 2 11:41:12 PDT 2013


02-Apr-2013 22:26, Jonathan M Davis пишет:
> On Tuesday, April 02, 2013 22:16:30 Dmitry Olshansky wrote:
>> 02-Apr-2013 21:48, Walter Bright пишет:
>>> On 4/2/2013 4:59 AM, Dmitry Olshansky wrote:
>>>> If somebody comes up with a reasonable Visitor pattern for Exceptions
>>>> that is
>>>> flexible and fast then sure let's see it.
>>>
>>> It doesn't really need to be fast. If you need performance out of
>>> Exceptions, you're misusing the idiom.
>>
>> The exceptions are slowish but that hardly justifies adding an extra
>> amount of overhead on top of that. This might as well push people to
>> avoid them even where it makes perfect sense to use exceptions.
>>
>> That being said let's see that beast and then measure, then optimize and
>> then judge it.
>
> D's exceptions are ridiculously slow (
> http://d.puremagic.com/issues/show_bug.cgi?id=9584 ).

Make sure you did the magic setStackTraceHandler(null);
or something to that effect I need to peruse druntime API to pinpoint 
the exact name.

It seems like debug hook dealing with traces is abhorrently slow and is 
called regardless of if you need to print it or not.

Otherwise they are exceptions like any other.

> Granted, in general, you
> shouldn't be relying on exceptions being efficient (they _are_ the error code
> path after all), but we really should do better than we're currently doing,
> and adding extra overhead obviously wouldn't help.
>

> The main area that I find exception speed to be a real problem is in unit
> testing. Solid unit tests will test error conditions, which generally means
> using assertThrown to verify that the correct exception was thrown for bad
> input, but with how slow D's exceptions are, it becomes _very_ expensive to do
> many tests like that, which is very frustrating when you're trying to do
> thorough unit tests.

Indeed exceptions vs error codes shouldn't be orders of magnitude deal.
If it is we need to do better job in implementation quality department.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list