Translator Exceptions – Development Strategy

The next incremental change was initially difficult to see for adding exception throws throughout the translator routines.  Starting at the bottom by changing the get token function to throw exceptions was problematic because all callers would have to catch the errors and create an error token to hold the column and length of the error.  Starting at the top by changing both the get expressions (used for testing) and get commands functions to throw exceptions was problematic because all functions in between would also need to be modified.  An attempt to change the entire translator was made.

After the code was modified and corrected for compile errors, the tests were run, but there were many problems, which was not unexpected considering the large number of changes made.  Instead of trying to debug, the changes were committed to a temporary work branch (though not pushed to the official GitHub repository).  This is a scheme to use git to temporary save work:

git checkout -b work           (create a temporary work branch)
git commit -a                  (stages all changed files and commits them)
git checkout -b misc-cpp-stl   (restore all files before changes)

This saved the changes of the failed attempt and restored the original files.  Changes from the work branch could now be transferred to the working directory piecemeal.  For example, several changes were made to the Token Error structure in the token header file (details in the next post).  For more details on using this scheme, click Continue...

I frequently use the vimdiff utility for comparing two files.  This command is just vim in difference mode.  Using git, files in other branches or commits can be compared.  The "git diff" command shows the differences between two versions of the files.  The most common forms of this command are:

git diff [commit-id] source-file
git diff [commit-id-1] [commit-id-2] source-file

The first form compares the source file in the current working directory to the version in the commit-id specified.  The commit-id can be the SHA1 hash code of the commit, a branch name, or a tag name.  A relative specifier can be added, for example, HEAD^ or HEAD~1 refers to the previous commit, HEAD^^ or HEAD~2 the second previous commit, an so on.  The relative specifier can also be used with a hash code, branch name or tag name (for example, work~2 refers to the second previous commit from the work branch; HEAD is just the name of the current branch).

The output of the diff is not very readable.  There is also the "git difftool" command that uses an interactive tool.  On my system, there are choices for 16 tools, but I primarily use vimdiff, which is accessed with this command (the -y tells it not to prompt for each file, and -t specifies the tool):

git difftool -y -t vimdiff [same arguments as git diff]

If the tool option is not specified, an appropriate default is chosen.  On my system, this is the kompare utility, which is a nice GUI based comparison program.  However, while kompare allows differences to be applied selectively, the changes applied cannot be edited further.  Admittedly, vim is not the easiest text editor to use (though it is my favorite after 25+ years of using it and its predecessor vi).  One note when using vimdiff, vim starts in read only mode, so in order to save an edited file (in the working directory only), read only mode must be turned off, which is accomplished using the :se noro (set no read only) command inside vim.

Since the above command is lengthy, a git alias can be created for the command (where "vid" stands for vi in difference mode, through any name can be used):

git config --global alias.vid "difftool -y -t vimdiff"

With this alias (available outside the current repository when the global option is used), the above command can now be entered as:

git vid [arguments as described above]

Entering no arguments will bring up each modified source file one at a time.  This is nice to use before making a commit to possibly edit the changes, for example, adding comments or finding and correcting misspelled word in comments.  (The git gui tool is also good for reviewing changes, but changes cannot be edited and it does not show misspelled words in comments.)