The DATA statement defines a row in a "table" that you then iterate over: RESTORE sets the "iterator", and READ dereferences the iterator and advances it to the next item. This is, in essence, a key-value "dictionary", and you could use the C#'s Dictionary container:
using System;
using System.IO;
using System.Collections.Generic;
public class Program
{
Dictionary<int, string> errors = new Dictionary<int, string>() {
[2] = "A syntax error has been found",
[3] = "Path not found",
[4] = "There is no more data" // etc.
};
This is how you'd approach it if you actually needed such a dictionary. C# offers powerful error diagnostic capabilities, and you don't need to manually manage error message dictionaries. The errors are called exceptions, and the exceptions can be caught, and they convey lots more information than what you had in most BASICs.
Here's the closest equivalent code for error handling a failing file opening:
void someMethod() {
object stream;
try {
// Presumed equivalent of line 460
stream = File.Open("path", FileMode.Open, FileAccess.Read);
// Line 470 would be here
} catch (FileNotFoundException) {} // if the file didn't open, we just continue
// Line 480 onwards would be here
}
And here's how you could handle arbitrary errors, providing not only their description, but also a stack trace showing all the methods active (i.e. entered but not exited) in the current thread when the exception was thrown:
void doAndCatchErrors() {
try {
someMethod();
} catch (Exception e) {
Console.WriteLine("Error: {1}\nStack trace:\n{2}", e.ToString(), e.StackTrace.ToString());
}
}
};
C# is a bit like Java in that it doesn't support free functions: all functions must be methods within a class. They may be static functions - and then they act exactly as free functions would, but this way you're forced to locate them in a non-global namespace. Global scope functions don't scale, because in large projects you'd be constantly fighting name collisions. Imagine a project with several thousand free functions - you get access to that many in fairly simple projects, and some of them indeed have duplicated names but each name is in a separate class, and thus they don't clash.
Now a more general note: it'd be extremely rare that a BASIC program would be structured like and use idioms similar to a good and readable C# program. Those are, after all, separate programming languages, and the most common, understandable and idiomatic way of expressing an idea in BASIC will most likely be extremely clumsy and appear alien in C#. Even programs that were "ported" from BASIC should not really resemble the original code when you re-express them in C#, because the vocabulary of both languages is quite different in scope: modern C# is way, way more expressive than any BASIC, and I'm not exaggerating here at all. The data structures and operations that had to be implemented from scratch in BASIC will likely be found in the framework you target your C# program to (that would be .Net Core framework for modern stuff) - so I expect that any BASIC program re-written in C# will be shorter, easier to maintain, easier to understand, and will perform potentially much better as well.
