opDispatch, duck typing, and error messages

Adam D. Ruppe destructionator at gmail.com
Thu Apr 21 16:39:31 PDT 2011


Jonathan M Davis wrote:
> It _does_ generally make sense for the file and line number to be
> from the throw point rather than the point where you called the
> function (especially when the throw point could be several function
> calls away in the stack), but without a proper stack trace, you
> have no way of knowing where in your code the problem is.

I believe I agree completely.

> Now, in the case of something like to, the types are known at
> compile time, so in many cases, it should be able to give a
> compile time error via a template constraint, but it's not able
> to do that in all cases.

Indeed. And it usually does. The problem is that the error can be
pretty hard to read.

Here's one simple case:

===

import std.conv;

struct Test {}

void main() {
	Test t;
	int a = to!int(t);
}

===

/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) && isSomeString!(T) &&
isInputRange!(Unqual!(S)) && isSomeChar!(ElementType!(S))) does not match any
function template declaration
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) && isSomeString!(T) &&
isInputRange!(Unqual!(S)) && isSomeChar!(ElementType!(S))) cannot deduce template
function from argument types !(int)(Test)
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
instance errors instantiating template
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(7): Error: template instance
std.conv.to!(int).to!(Test) error instantiating


Holy crap!

But, if you know the secret there - to look at the last line -
it does tell you enough to do some useful stuff. Alas, it doesn't
tell where in *your* code the problem is, but it does tell the
types you asked for, so it's pretty useful.

Still, I'd like it if that was formatted nicer, and it went the
final step of telling me where in my code the problem is too.


Then, you have the problem if your type matches two templates.
Then you have the vomit in my opening post, where it doesn't even
tell you what types it's having trouble with!

> One example of that is converting a string to anything else. The
> value of the string determines whether the conversion is valid
> rather than the types being enough at compile time.

The runtime error is actually pretty good. If it had a nice
stack trace with line numbers I'd call it outright excellent.


So I agree with your conclusion too about the stack trace!


BTW, while I'm talking about this, is RangeError at all possible
to include the actual key that was out of range?

	int[] b;
	int c = b[3];
core.exception.RangeError at test60(7): Range violation

Good, but I'd call it great if it could say Range violation (3) or
something like that.

I imagine since it's an Error there might be memory allocation
restrictions... but if it's possible, that'd be way cool too.


More information about the Digitalmars-d mailing list