On Saturday, July 8, 2017 12:55:46 AM MDT FoxyBrown via Digitalmars-d wrote:
> I came across some error in heap sort. Was erroring out on the
> wrong. A few lines below the assert existed but no error message
> associated, why is it so hard to not write a few extra EXTREMELY
> helpful error messages?
>
> assert(isHeap(r), "This is an ERROR AT THIS
> LOCATION"~__FILE__~"("~__LINE__~")");
>
> etc?
>
> It should be mandatory that all asserts, throws, etc provide
> correct information about not only the point of the error but
> also the location and what caused it. These things are not
> irrelevant but affect all those that use it... imagine the real
> human man hours that could be saved if such things were done.
>
> It would be easy to find all the bad asserts?AssertError already provides the location of the assertion, and it uses __FILE__ and __LINE__ to do it (_all_ Exception types do that unless the person who wrote the class screwed up the constructor), so adding them to the message it pointless and redundant. If the assertion failure is printing out the wrong line, then it's likely either because you're looking at the wrong version of the code or because a string mixin is screwing with the line numbers (which IMHO, shouldn't happen, but it at least used to be a problem). In addition, the AssertError should be giving you a stack trace, which _should_ have the file and line numbers in it of every call in the stack (though stupidly, the line numbers don't always work, depending on your OS). So, you _should_ have had that information by the simple fact that an AssertError was thrown, and unless the assertion itself needed additional explanation beyond the condition that failed, then a message wouldn't have helped anyway. So, if the file and line number was wrong, the question is why, and that should be fixed. And we really need to figure out how to make it so that the issue of not having line numbers with stack traces goes away and stays away. The fact that it's been a problem is ridiculous, because file and line numvbers in stack traces are critical for debugging. - Jonathan M Davis
