When dealing with I/O there is rarely such a thing as too much error handling logic. Because PureBasic does not support exceptions we are only able to rely upon return values which typically amount to a binary success-or-failure.
As a preferences file is a file then like any file open operation you need to explicitly define what you want to do if the file does not exists, exists already, exists but is locked, exists but has no permission, etc.
The illusion here is that instead of using FileSize() to see if the file exists first you are using OpenPreferences(). The logic is still the same: you want to open the file if it exists; otherwise create and then open it. You are right to rely upon OpenPreferences() instead of FileSize() in this case as there may be other conditions within the OpenPreferences() function which might cause it to still fail. But even then, as it is I/O, there is always the inherent race condition between when you checked to see if the file exists and when you try to open it. With the exception of nuking it from orbit, generous error handling is the only way to truly be sure.
Cramming this behavior into OpenPreferences() might seem logical but is actually contrary to the behavior established not only in PureBasic's File library but also for many others'.
Instead of favoring if-true logic, try if-not-true as a method of escape. This has the added benefit of reducing the indentation of code, improving readability, and reducing logic complexity by minimizing the need for if-else blocks.
For example:
Code: Select all
If Not OpenPreferences(File,#PB_Preference_NoSpace)
;/ Handle error
ProcedureReturn
EndIf
;/ Continue executing