In Delphi Prism XE Update 1, this spring, we introduced a cool new concept to the editor: Inline Errors. When you compile your code project(s), you no longer have to look down to the Message Pane to see a (hopefully short) list of compiler messages; errors, warnings and hints now also show right in the editor, in form of red, yellow or green lines in your code, indicating error locations and error messages.
For Delphi Prism XE2 and for Project Cooper (which shares Delphi Prism’s compiler and IDE code base to a large part), we have decided to take things a bit further. In this post, I want to give you a sneak peek at three (actually three and a half) cool enhancements to error reporting coming this fall:

Additional Error Notes

Sometimes, you get a compiler error, but the line you’re looking at for the error really only tells half the story. There’s different places throughout your project that contributed to your error – maybe you’re calling a method, and the compiler is telling you the parameters don’t quite match.
In addition to seeing the offending line, wouldn’t it be nice to have easy access to related pieces of code as well? With Error Notes, there is. In addition to the “main” error, the compiler now reports other useful places that may help you narrow down the problem.
One example can be seen in the (a bit contrived) screenshot below: not only does the compiler tell you that you redeclared the same method twice – it also lets you know where the original declaration was. In this case it’s obvious – but your class could be more complex, and in other situations, notes could point you to different classes or different files in your solution.

![Error Notes](http://blogs.remobjects.com/wp-content/uploads/2011/06/ErrorNotes1.png)
## Error Ranges

Another scenario is that sometimes you get an error in a more complex expression, and you just can’t make heads or tails from where exactly the problem is supposed to be. Just the line doesn’t help. Even just the line and a range of characters doesn’t help. You need more info.
Consider the example shown below. Every Pascal developer’s favorite error: you forgot the parenthesis, and because “and” has higher precedence than “=”, your two comparisons don’t quite compile as expected. Once again, the case shown here is trivial, but the same kind of issue could be buried deeper in a more complex expression.
Inline Error ranges show you not one range of code responsible for your error, but actually subdivides your code, telling you exactly which parts contributed. In this case, you can see that it’s the second “=” operator that it is failing on, and which parts of its surroundings were (mistakenly) interpreted as operands.

![Error Ranges](http://blogs.remobjects.com/wp-content/uploads/2011/06/ErrorRanges1.png)
## Fix It!

Finally – let’s be honest: half the time you get a compiler message, and think to yourself “Gee thanx. If you can tell me that there’s a semicolon missing, can’t you just add it for me?” With Fix Its, the compiler can! For select compiler errors and warnings where there’s a clear solution, the compiler can now suggest ways to fix the error – and the IDE can let you pick and apply a fix with a single click. Done.

![Fix It](http://blogs.remobjects.com/wp-content/uploads/2011/06/FixIt1.png)
What’s more – we’ve also taught the compiler to “pretend” errors were fixed, and continue compiling. So even though the compiler might give you an error for not knowing the type for “var x: Foo;”, the rest of your error list won’t be speck’ed with errors for all the methods you call on “x” that the compiler doesn’t know about.

More to Come

This is just a sneak peek at one set of new features coming this fall. Stay tuned for more.
Read more about Delphi Prism (Oxygene for .NET) at remobjects.com/prism.
Read more about Project Cooper (Oxygene for Java), currently in beta, at remobjects.com/cooper.