On 02/11/2013 05:12 PM, Sven Barth wrote:
On 11.02.2013 13:18, Sven Barth wrote:
Am 11.02.2013 13:06, schrieb Giuliano Colla:
Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
3) But if also the *path* to the file doesn't yet exist, it just
crashes without rising an exception that the user application can
handle somehow.
This is incorrect. It does tell you why it fails.
This is rather unpleasant, because the path provided by
GetAppConfigXx does usually exist, so you have an application
which 99% of the times works just fine, and 1% of the times
crashes without telling why.
It tells you *exactly* why it 'crashes':
home: >./ti
An unhandled exception occurred at $000000000042AE87:
EFCreateError: Unable to create file "/tmp/path/to/nothing.txt"
$000000000042AE87
This is true only if you invoke the program from command line, which
is something the end user will never do.
That is not the problem of TIniFile, but of the application
programmer.
TIniFile properly reports any error, as it should, with an exception.
It is always up to the application programmer to deal with such cases.
That this is sometimes tricky in a GUI application, cannot be helped.
It can be helped both by reducing the likelihood of the event, as
you've done, and by not suggesting to use in that case a try..finally
construct in a GUI application, which would mask the errors.
The "try..finally" itself will not mask the error. The error will
propagate to the next surrounding "try..except" handler (executing the
code in all finally sections it encounters) and normally this will
result in a dialog being displayed (if you did not change
Application.OnException). It could be however that you try to create the
configuration file when the usage of GUI is no longer possible (I don't
know).
Just to prove my point: I wrote the following little test program in
Lazarus. Add a button to a empty form and assign the OnCreate and
OnDestroy events of the form and the OnClick event of the button and
add the following code to them:
=== snippet begin ===
procedure TForm1.FormCreate(Sender: TObject);
begin
try
raise Exception.Create('FormCreate');
finally
MessageDlg('FormCreate Finally', mtInformation, [mbOK], 0);
end;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
try
raise Exception.Create('Button1Click');
finally
MessageDlg('Button1Click Finally', mtInformation, [mbOK], 0);
end;
end;
procedure TForm1.FormDestroy(Sender: TObject);
begin
try
raise Exception.Create('FormDestroy');
finally
MessageDlg('FormDestroy Finally', mtInformation, [mbOK], 0);
end;
end;
=== snippet end ===
If you now run the application (for now I assume you run it without a
debugger or outside the IDE) you first get the "FormCreate Finally"
dialog, then a "Exception "FormCreate" occured" dialog and then the
form will be display. An analogous event will happen if you click the
button and as well when you close the form.
So it would be nice if you'd show where exactly no error message is
displayed for you (preferrably with a compiling code example).
I extracted from my code a minimal example, and I too can see the
exception dialog, which doesn't show in the main application.
I don't see why the extra code should create a problem, but, by adding
one piece after the other I should be able to find out where the problem
comes from. However, replacing the original try..finally with a
try..except, the main application behaves properly, but in that case
it's the application which pops up the error dialog.
Giuliano
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
