opDispatch, duck typing, and error messages

[Jonathan M Davis]

> Adam D. Ruppe:
> > c) Maybe Phobos could help out somehow? Another thing to!()
> > annoys the living crap of me with is it's runtime errors. It, again,
> > doesn't tell me where in my code the problem occurred.
> > 
> > Perhaps have it take default __FILE__ and __LINE__ args to print out
> > too? I think this can help both compile and runtime errors.
> 
> This is a more general problem of runtime errors, not just of to!(). Maybe
> exceptions nature should be changed a little so they store __FILE__ and
> __LINE__ on default (exceptions without this information are kept on
> request, for optimization purposes).

Most exceptions end up with file and line numbers. The problem is generally 
not that they don't have a file or line number, it's that the file and line 
number is from inside of a function that you called instead of your own code. 
As long as you have a stack trace, it's not all that big a problem, but if 
you're on Windows, then there are no stack traces yet and you're screwed. 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.

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. 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. So, in some cases, you _have_ to have an exception at runtime rather 
than a compile time error. Whether to does as good a job with making errors 
compile time errors as much as it can, I don't know, but on some level, we're 
stuck.

But generally, I think that the real problem is the lack of a stack trace. You 
generally get them on Linux but not Windows. Most exceptions _should_ be 
grabbing the file and line number that they're thrown from. I don't recall of 
Exception can or not (Error _can't_ due to some low level stuff), but pretty 
much everything derived from Exception certainly can and should.

- Jonathan M Davis