Blog

There is only one way to abort a user action in Microsoft Dynamics NAV: by using the ERROR function. This function essentially stops the execution of all code, and prevents completion of the user action, whatever such action might be.

One of typical situations where ERROR is used to prevent user action is during validation of a new value in a field. A typical concrete example of this behavior is entering the Customer No. value in the Sell-to Customer No. field on the sales order form. When users enters a value, the system goes through a series of checks, called validation, which in the end may result in the system rejecting this value. Obviously, the only way for the system to reject a value entered by the user is, yes you’ve got it, by calling the ERROR function, which returns the system to the last committed state before the error.

In certain situations, the system may not just decide that a value is to be rejected, and it might require user assistance in this. Another typical example of this situation is when you try to create a sales order for a customer who is over the credit limit. I wouldn’t want the system to just decide on my behalf that sorry we can’t sell to this customer, so the system is nice and it asks me. Do, or do I not, still want to sell to this customer? Let’s say that I say no. At this point, we know that we don’t want to sell anything to this customer, but guess what happens? This:

Now this is one ugly error message. It is ugly because it doesn’t tell you much, and has a tremendous potential to both confuse and annoy you, not necessarily in that order. It doesn’t tell you much because you were the one who decided not to continue, you already aborted the process and you know it is going to be aborted. In normal situations, when error happens, it happens because something went wrong, and you can bet your kidneys that whatever went wrong did so as the result of whatever you did last. However, in this case, for starters, nothing went wrong, the system asked you a question, you answered the question, and now there is an error. Huh? Is something wrong with my answer, or is something wrong with my data entry? Or why is anything wrong at all? Ok, yeah, there was the text message that explained exactly what happened, but truthfully, how many users really read error messages before they panic? All most of them see is an error. And an error implies something went wrong, and when something goes wrong, guess whose telephone is going to ring next? This is one ugly error message, believe me.And this is not the only situation in the system, where the system does this to you. There are many others. When you write your own code, you migth be tempted to do exactly the same thing, trowing an error in the user’s face just for not confirming something, something like this:

IF NOT CONFIRM('Do you want to continue?') THEN
  ERROR('The update has been interrupted to respect the warning.');

Pleaase, for crying out loud, don’t do this. There is a better way, and it goes like this:

IF NOT CONFIRM('Do you want to continue?') THEN
  ERROR('');

This is a silent abort approach: the system aborts the execution, as with normal error, only it does so silently, not showing any error message whatsoever. You don’t confuse the user with an error, because an error implies that something went wrong, rather you just comply with the user’s choice and abort the execution with no fuss about it.

Funny thing is that if you search through the code, you will see that there are examples of both approaches, so there is no way one could argue that only one of those is standard, when obviously both of them are. The thing is, the second one is better. Way better.