More verbose lib/ output / error reporting, less debug breakpoints / SIGTRAP

[elexis]

If GetDirectoryEntries of source/lib/file/file_system.cpp encounters a dangling link, Pyrogenesis triggers a SIGTRAP / debug breakpoint, and to the user it appears like a serious program error has occurred and the broken must be considered defunctional and has to be restarted.

This has happened to me when I used a link for mod consuming several gigabytes on a different disk and later deleted the mod.

Since dangling links are a user, not program error, the exception should be caught or not be triggered. The program must report the user error to the user, then the program can either ignore the link and continue the program, or report and exit, so that the error receives the full attention of the user.

Index: source/lib/file/file_system.cpp
===================================================================
--- source/lib/file/file_system.cpp	(revision 21931)
+++ source/lib/file/file_system.cpp	(working copy)
@@ -117,11 +117,14 @@ Status GetDirectoryEntries(const OsPath&
 #else
 		// .. call regular stat().
 		errno = 0;
 		const OsPath pathname = path / name;
 		if(wstat(pathname, &s) != 0)
+		{
+			debug_printf("Could not list directory contents at \"%s\"\n", pathname.string8().c_str());
 			WARN_RETURN(StatusFromErrno());
+		}
 #endif
 
 		if(files && S_ISREG(s.st_mode))
 			files->push_back(CFileInfo(name, s.st_size, s.st_mtime));
 		else if(subdirectoryNames && S_ISDIR(s.st_mode) && name != L"." && name != L"..")

If I recall correctly, debug_printf is not displayed in the Windows terminal, and we would preferably want to write to the logfiles (mainlog.html). However source/lib/ doesn't have the logger, and the functions calling into source/lib/ functions don't know the specific item (dangling link) to warn about.

In r19540 we encountered the same problem.

So it seems all status return values, and their reporting in source/lib/ needs to be revisited, to determine whether debug breakpoints occur on user-issue or whether they truly warrant a user to report it as a program error and a developer to initiate a search for a program bug.

[Stan]

If I recall correctly, debug_printf is not displayed in the Windows terminal, and we would preferably want to write to the logfiles (mainlog.html). However source/lib/ doesn't have the logger, and the functions calling into source/lib/ functions don't know the specific item (dangling link) to warn about.

The fact that it doesn't display debug_printf in the console is not a big deal actually, because unlike OSX, MacOs and Linux, 0 A.D. does not open a command window when it launches on Microsoft Windows.

If someone wants to get the output he either has to use the very good ​DebugView

Or use Visual studio as a debugger where he'll get the output in the Output Pane of that software.

I agree that reporting errors the same everywhere would be nice though.