Better error messages

Hello all,

I keep running into opaque error messages from time to time and was wondering if the core team has plans to address them anytime soon–

  1. An arithmetic overflow caused the compiler to crash and generate a “error when including file” (sorry couldn’t be exact, I copied the error and crash info somewhere but now can’t find it!), there was no way to know which line caused the issue.

  2. Method resolution fails with “Error: no overload matches …” but doesn’t specify which arg (and type) failed to match – this makes it really difficult to pin-point which one is causing the trouble when the method takes a lot of arguments (think orm row initialization).

That aside, I’ve jumped in both feet on some projects I’ve been wanting to work on (that I was hesitant to write in Go) and Crystal makes it so much more enjoyable! Thanks to the core team and all the contributors for bringing us this wonderful language and a rock solid stdlib!

Thanks!

2 Likes

I definitely think the No overload matches message could be improved by placing the expected and got on new lines as the signatures would be aligned.

I find myself jumping into an editor and doing that exact thing with the error message to see exactly where the mismatch happens.

5 Likes

Having good error messages is an important goal. We are aware that some errors may not be very useful sometimes.

But it’s hard to talk about this generically, so it would really be helpful to point out specific examples, like “this code produces this error and the message is bad”.

There might already be some discussions on some of the error messages, if you have a concrete example, try searching the issue tracker on Github if there are any references.

@straight-shoota Thank you, yeah I imagined so. But I wanted to put it out there. I’ll share more soon but I know this much about the arithmetic overflow problem I mentioned earlier – I had all sorts of data conversion from strings to integers and floats and dates that produced this. Like I said I couldn’t pin-point the exact line that caused it but once I removed these conversions the error disappeared. It was a fatal compiler crash and even trying to compile with --error-trace didn’t help a bit except for the “error requiring the {file}”

As far as the method resolution issue goes, I agree with @caspiano, something like expected and got or even a simple ----^ (pointer like indicator) would be nice.

Thanks!