On 02/12/2013 02:46 PM, Mark Morgan Lloyd wrote:
Giuliano Colla wrote:
On 02/12/2013 10:02 AM, Mark Morgan Lloyd wrote:
I admit that I was slightly trolling there, since Giuliano was
complaining about exceptions that he wasn't seeing (because, it
turns out, he wasn't catching them).
You catch an exception if you can handle it. If a user for some
reasons has write-protected a configuration file, there's nothing the
application can do about it. One can usually rely on the system
default exception handler to show the error message. If it doesn't
happen, then there's something wrong somewhere.
Yes, but the point that I'm trying to get across is that the earlier
you make sure that you've got full access to the files (i.e. all
directories in the path exist, the file either exists and is writable
or you create it from a template) the easier you make life for
yourself. If having the file is absolutely essential then check for it
before you even open the main form and bomb if it's obvious that
there's a problem.
That's the point. The configuration file in this application is useful
but not essential. It holds fine calibration data for a set of remote
sensors. If you can't read it, you must click again on the "Calibrate"
button a number of times, to display more precise values. One could even
chose to write-protect it, to avoid overwriting a good calibration.
It's not a DataBase application where if you don't set the right
hostname, user and password you can't do a thing.
That's why I would have been perfectly happy with a default system error
box telling "write error", or whatever, just to let know that the data
have not been saved.
What happens on the contrary is that, in case of failure, no error is
shown, and, what's more annoying, that the form can't be closed, which
can be quite confusing for a normal user.
Giuliano
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
