Error handling with the user

One of my development strategy for software tools is to always give a result and working in cooperation with the user. Here are my three basic rules:
1.Software must always output some result
2.Communications with the user must be done by using the current data format
3.Errors must be clearly identifiable compared to normal outputs

Rule #1) Software must always output some result
Software should never just stop. If a minima is reached, a meaningful descriptive of the problem should always be displayed. If an algorithm fails halfway through execution, that first half should be displayed. Why is that important? Because the point at which it stopped is the biggest clue you'll ever give to the user on 'why it failed' and it's the biggest lead for the user on 'how to fix his inputs'. It is of course imperative that those errors outputs are non-destructive to the rest of the data.

Rule #2) Communications with the user must be done by using the current data format
Why use a different language than the one utilized by the user? Imagine that a problem occurs when doing some calculation base on vector data in 3DS Max (a 3D modeling software). Lets say that the problem lies in one of the vertices (points). Your code is trying to process the problematic vertex but it can't. Why? There's about as many reasons that there is users and 3DS drawings, so forget the reason. Of course if you just display a text box trying to describe the problem, it might have a chance at helping the user. But if you highlight the problematic vertex and pan/zoom to it, now that's helping the user. You don't have to do this in the original file. You can use a separate file but keep a similar medium. If the user is doing vector graphics use vector graphics.

Rule #3) Errors must be clearly identifiable compared to normal outputs
Highlight the errors and the thing that you're not sure about. An errors as to be flagrant, make it bold and use red a lot. The user should be able in one glance to identify the problems but still recognizer the surrounding data. This ability to see the bad data in its real context is the key for the user to quickly see the problem.

A good example of this way of working is MS Words handling of typos. While you type, it highlights errors but never stops your actions. You can then fix the problem(s) whenever you want and they're easy to fix because they're in context.