I hate runtime errors. I think that functions in C/AL that can generate runtime errors should be deprecated where possible or altered in their function. Let me explain with an example.
Let's say you have two fields both called Description on two different tables. One of your tables is the Item table and the other is a new table called "New Item" (OK so I'm not going to win any prizes for imaginative table names in this example.) You want to make an assignment from one field value to another so you would do something like this:
l_NewItem.Description := l_Item.Description;
When your code runs the Description gets copied across and everyone's a happy bunny. But, let's say your customer says they want their item description to be made 20 characters bigger. What happens then?
Well let's assume that you increase the size of the Item Description field by 20 characters. Everything still works. Or so you think.
When NAV executes the line of code that previously worked fine on a record that has more characters in the new larger string than will fit in the other string, you (or more likely the first user that comes across that bit of functionality in your production system) will get a Runtime Error. Blurgghhh!
I have programmed in a few languages and C/AL is the only language I have ever come across that does this. What would other languages do? They would truncate the value and continue. They would assume, "hey, the programmer wants me to put a 50 character string in a 30 character string, he must know what he's doing, so I'll just give him as much as I can."
I like that, it's friendly, it makes me feel warm and fuzzy. Why can't C/AL do the same?
But there is a far worse function that can throw runtime errors and this should be banned altogether! TRANSFERFIELDS.
TRANSFERFIELDS is evil. It has to go.
What does it do? Well it, er, transfers, erm, fields (duh?) It is used to transfer fields from one table to another. Sounds cool doesn't it? How does it decide which fields should be copied? It uses the field ID.
What? The totally arbitrary field ID? Surely not, that would be crazy. Yup you heard it the field ID. NAV will attempt to make an assignment between two fields with the same ID, but different names and different types. And what do you think happens if the field types are incompatible?
Run Time Error.
The reason this function is evil is it lures the unsuspecting programmer into its little trap. It looks innocent. It looks like it may save you some time. Don't be lazy. Assign the fields one by one. Think about it, if you have 10 lines of code that assign each field from one table to another, anyone reading your code knows exactly what is happening. If you really want to be good, create a function on the table called CopyFromItem() or something similar. Then do the field assignments in the function so your code would look something like this:
l_NewItem.CopyFromItem(l_Item);
Now isn't that better?
So what prompted me to have this little rant? Well I am doing an upgrade from v3.70 to v5.00 at the moment and the damn thing just failed with a run time error. Some of the code in the standard upgrade toolkit gave me this error message:
The two fields below must have the same type:
Field: JobTaskNo <-- Table
Table: Temp Job Task Phase Step Comb. <-- Temp Phase Step Task Doc Line
Type: Code20 <-- Integer
Can you guess what caused this error?
TRANSFERFIELDS!
So if the expert coders at Microsoft get caught out, what chance do we have?
