On 2011-03-30 14:05, Ali Çehreli wrote: > On 03/30/2011 12:40 PM, Jonathan M Davis wrote: > > On 2011-03-30 05:09, spir wrote: > >> On 03/30/2011 05:32 AM, Ali Çehreli wrote: > >>> On 03/29/2011 03:40 PM, Kai Meyer wrote: > >>>> I was given two words of advice on exceptions: > >>>> "Use exceptions for the exceptional" > >>>> "Use exceptions only for the exceptional" > >>> > >>> Those advices are given by wise people: they are wise only because they > >>> leave the definition as vague as "exceptional." :) > >>> > >>> And what do we do for the "not so exceptional"? Do we return error > >>> codes? So the function implementation will be complicated and the > >>> caller code will be complicated. > >>> > >>> Exceptions are a great tool to eliminate the need for error codes. > >>> > >>> Here is what I follow: > >>> > >>> - Functions have specific tasks to do; if those tasks cannot be > >>> accomplished, the function must throw. > >>> > >>> In some cases the function can continue, but that behavior must be > >>> documented. For example, if an HTML library function is responsible for > >>> making HTML headers, of which only the levels in the range of 1-6 are > >>> valid, that function may throw when the level is outside of the valid > >>> range, for in that case it cannot "make an HTML header"; or it can > >>> document that if the level is outside of the range, 1 or 6 will be > >>> used. > >>> > >>> - Catch exceptions only when there is a sensible thing to do at that > >>> level: log an error, skip that operation, go back to the user with an > >>> error code, take corrective action, etc. > >>> > >>> Disclaimer: That is what I follow in C++ code. I don't have experience > >>> with exception safety in D. I don't know issues that may be specific to > >>> D. > >> > >> These are sensible and well expressed guidelines, thank you. > >> In other languages, I happened to use exceptions as a // channel for > >> side-information (eg 'nomatch' for a matching func), but in D I realised > >> how 'exceptionnally' (!) costly throwing& catching exceptions is, so > >> that I do not do it anymore. No idea though whether this exceptional > >> cost is perticular to D. > > > > I'd have to measure it in C++, Java, and C#, but I'm pretty sure that D's > > is at least a lot slower than Java. Java uses exceptions all over the > > place, and it works quite well overall IMHO, but I never got the > > impression that there was any kind of major overhead for exceptions > > (though obviously there's going to be at least _some_ performance hit > > for derailing the thread of execution like that). In D however, it seems > > to be significant. As I've been reworking std.datetime's unit tests, > > I've found that I've had to be very careful about how often I use > > assertThrown, or there is a _major_ increase in how long the unit tests > > take to execute. While changing some tests, I had some loops which > > included assertThrown. It turns out that with assertThrown, they'd be > > 10+ seconds long, whereas without, they'd be a matter of milliseconds. > > So, the performance of exceptions in D is quite poor and while it > > probably doesn't matter all that much for normal code execution, it's > > definitely annoying for heavy unit testing which is validating that > > functions throw when they're supposed to throw. > > > > As a test, on my machine, this program > > > > === > > import std.datetime; > > import std.exception; > > import std.stdio; > > > > void main() > > { > > > > auto date = Date(2011, 5, 7); > > { > > > > auto curr = Clock.currTime(); > > assertNotThown!DateTimeException(date.day = 29); > > writeln(curr - Clock.currTime()); > > > > } > > > > { > > > > auto curr = Clock.currTime(); > > assertThrown!DateTimeException(date.day = 32); > > writeln(curr - Clock.currTime()); > > > > } > > > > } > > === > > > > prints out this > > > > -1 μs and -4 hnsecs > > -637 μs and -7 hnsecs > > That's too much. :) I get consistent results with -O on a 64-bit Ubuntu: > > -1 μs and -9 hnsecs > -832 μs and -9 hnsecs > > But with the addition of the -m64 flag, it's more than 4 times faster: > > -1 μs > -175 μs and -4 hnsecs > > Still not good. :-/
LOL. And I just realized that I did those subtractions backwards. They're negative where they should be positive. Oh well. The numbers are still clear, and I was in a hurry when I wrote the test code. - Jonathan M Davis