https://issues.dlang.org/show_bug.cgi?id=17102
Vladimir Panteleev <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |[email protected] Resolution|--- |WONTFIX --- Comment #3 from Vladimir Panteleev <[email protected]> --- (In reply to donte5379 from comment #2) > I think that std.file.write should throw an exception before the null gets > passed to the C API. I don't think it's the job of the standard library to validate that the input parameter is valid before passing it to a C API. > Even if I add a try-catch block all I see is a message > "Segmentation fault" on the terminal. > > std.file.write(file_name, the_text); > } catch (Exception e){ > writeln(e); > } Writing to a file whose file name is unset is a logic error in the user's code, so if such a check would be present in std.file.write, its correct behavior would be to throw an Error, which would also bypass your try/catch block (as you only catch an Exception), so the program would behave similarly. The main difference would be that on POSIX, by default the D runtime doesn't attempt to handle and print a stack trace on unhandled signals (which would otherwise terminate the program). On Linux, there exists etc.linux.memoryerror, which translates segmentation faults to D exceptions. On Windows, access violations are already translated to D exceptions through D's support for Windows structured exception handling. Either way, finding the cause of the segmentation fault would have been as simple as running your program under a debugger. > As an added frustration the redirection is corrupted in bash (and tcsh) and > so it is difficult to run dustmite. The DustMite documentation contains examples on correctly reducing segmentation faults. I've also created a page to explain the basics: https://github.com/CyberShadow/DustMite/wiki/Reducing-a-segmentation-fault --
