Fpc Access Violation if AppConfigDir doesn't exist.

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Mark Morgan Lloyd-5
Sven Barth wrote:
> On 11.02.2013 15:30, Mark Morgan Lloyd wrote:
>> If anything, it is the fault
>> of AppConfigDir for indicating a directory without raising an exception
>> pointing out that it doesn't yet exist :-)
>>
>
> And AppConfigDir/File is documented as not guaranteeing that the path to
> the directory or file exists. This also includes upper parts of the
> path's tree.

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).

However I feel that my point stands: if the program opens, checks and
closes the .ini file before the main logic starts, then it's possible to
keep those initial activities separate from any try-finally required by
the application logic. This initial activity obviously still requires
both a try-finally and a try-except, which is where he was going wrong
with his initial attempt.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internallinker problem)

el_es
In reply to this post by Gerhard Scholz
On 11/02/2013 23:19, Gerhard Scholz wrote:
> I switched to AVAST free Antivirus now, the problem does not occur here.
>
> This is not a pascal question, but maybe can give me a hint if AVAST is good
> or which software is more recommendable.
> (I do not really trust the tests I find in the internet because I do not know
> who pays them)
>
> Gerhard
>
I found myself recently quite comfortable using ZoneAlarm.

L.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla
In reply to this post by Sven Barth-2
On 02/11/2013 09:14 PM, Sven Barth wrote:
> It would be nice if you could minimize the problemematic code further
> step by step so that we can see what caused the "missing dialog".
> Maybe it's a bug somewhere else...
>
I've made some further experiments with my minimal test.
Test form is just a Form with a Close button (BitBtn Kind=bkClose).
The full code is the following:

unit uinitfile;

{$mode objfpc}{$H+}

interface

uses
   Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, Buttons,IniFiles;

type

   { TForm1 }

   TForm1 = class(TForm)
     BitBtn1: TBitBtn;
     procedure FormClose(Sender: TObject; var CloseAction: TCloseAction);
     procedure FormCreate(Sender: TObject);
   private
     { private declarations }
   public
     { public declarations }
   end;

var
   Form1: TForm1;
   ini: TIniFile;
   AppConfigFileName: string;
   SomeData: boolean;
   SomeOtherData: boolean;
implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
begin
  AppConfigFileName:= '/not/existing/path/inifile.cfg';
  ini := TIniFile.Create(AppConfigFileName);
  try
    SomeData:= ini.ReadBool('Section','Val',true);
    SomeOtherData:= ini.ReadBool('Section','Val1',true);
  finally
    ini.Free;
  end;
end;

procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
begin
   ini:= TIniFile.Create(AppConfigFileName);
{$DEFINE Finally}
{$IFDEF Finally}
   try
     ini.WriteBool('Section','Val',SomeData);
     ini.WriteBool('Section','Val1',SomeOtherData);
   finally
     ini.Free;
   end;
{$ELSE}
   try
     ini.WriteBool('Section','Val',SomeData);
     ini.WriteBool('Section','Val1',SomeOtherData);
   except
     MessageDlg('Error while writing '+AppConfigFileName,mtError,[mbOK],0);
   end;
   ini.Free;
{$ENDIF}
end;

end.

One may test two conditions: with try..finally and with try..except.
Even with this minimal sheds some light on the matter.

Try..finally situation, with IDE and Debugger.
Press the Close button. A debugger error notification is shown. Pressing
"Continue", an error dialog is displayed: "Unable to create ... press OK
to Ignore...etc.":
Pressing OK (no harm should come, just the file can't be written) the
form isn't closed as it should, and it's still there.
Pressing again the close Button, FormClose is executed again, and the
same dialog is shown. No way to close the form, unless you press Cancel
on the error dialog.
Why FormClose doesn't close the form in presence of an error (handled by
a try..finally) when writing the ini file?
Launching from command line, you have the same behavior, and an
additional information when you select Cancel:

WARNING: TLCLComponent.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?


Try..except situation, from IDE and Debugger.
Press the Close button. Debugger Notification. Pressing Continue my
message dialog is shown. Pressing OK on my dialog the form is closed and
the program is terminated.
Launching from command line, no console messages.

My conclusion is that one can't properly handle INI files with just a
try..finally construct, as all examples show, because a possible error
will propagate outside the construct, with unpredictable effects (in
this case the FormClose procedure doesn't properly complete).

Giuliano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

José Mejuto
El 12/02/2013 13:29, Giuliano Colla escribió:

> My conclusion is that one can't properly handle INI files with just a
> try..finally construct, as all examples show, because a possible error
> will propagate outside the construct, with unpredictable effects (in
> this case the FormClose procedure doesn't properly complete).

Hello,

Finally always propagate the exception bubbling up looking for other
exception handler, and that's its job, in comparation to except handler
which "eat" the exception and if you need to propagate it again you must
"Raise" in the exception handler.


--

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla
In reply to this post by Mark Morgan Lloyd-5
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.

Giuliano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Sven Barth-2
In reply to this post by Giuliano Colla
On 12.02.2013 13:29, Giuliano Colla wrote:
> On 02/11/2013 09:14 PM, Sven Barth wrote:
>> It would be nice if you could minimize the problemematic code further
>> step by step so that we can see what caused the "missing dialog".
>> Maybe it's a bug somewhere else...
>>
> I've made some further experiments with my minimal test.
> Test form is just a Form with a Close button (BitBtn Kind=bkClose).
> The full code is the following:
[snip]
> One may test two conditions: with try..finally and with try..except.
> Even with this minimal sheds some light on the matter.
>

It indeed does, but not as you think.

> Try..finally situation, with IDE and Debugger.
> Press the Close button. A debugger error notification is shown. Pressing
> "Continue", an error dialog is displayed: "Unable to create ... press OK
> to Ignore...etc.":
> Pressing OK (no harm should come, just the file can't be written) the
> form isn't closed as it should, and it's still there.
> Pressing again the close Button, FormClose is executed again, and the
> same dialog is shown. No way to close the form, unless you press Cancel
> on the error dialog.
> Why FormClose doesn't close the form in presence of an error (handled by
> a try..finally) when writing the ini file?
> Launching from command line, you have the same behavior, and an
> additional information when you select Cancel:
>
> WARNING: TLCLComponent.Destroy with LCLRefCount>0. Hint: Maybe the
> component is processing an event?
>
>
> Try..except situation, from IDE and Debugger.
> Press the Close button. Debugger Notification. Pressing Continue my
> message dialog is shown. Pressing OK on my dialog the form is closed and
> the program is terminated.
> Launching from command line, no console messages.
>
> My conclusion is that one can't properly handle INI files with just a
> try..finally construct, as all examples show, because a possible error
> will propagate outside the construct, with unpredictable effects (in
> this case the FormClose procedure doesn't properly complete).

The problem is not INI files, but more how OnClose is handled. OnClose
is called whenever the user tries to close the form and if an assigned
event handler raises an exception it seems that the calling code assumes
that the form should not be closed. In my example I used OnDestroy which
seems to be handled more gracefully.

I'd suggest you to ask on the Lazarus list whether it is intentionally
that you can't close a form of which the OnClose event handler raises an
exception.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Michael Van Canneyt


On Tue, 12 Feb 2013, Sven Barth wrote:

> called whenever the user tries to close the form and if an assigned event
> handler raises an exception it seems that the calling code assumes that the
> form should not be closed. In my example I used OnDestroy which seems to be
> handled more gracefully.
>
> I'd suggest you to ask on the Lazarus list whether it is intentionally that
> you can't close a form of which the OnClose event handler raises an
> exception.

This is also so in Delphi. Just tested.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Mattias Gaertner
In reply to this post by Giuliano Colla

Giuliano Colla <[hidden email]> hat am 12. Februar 2013 um 13:29
geschrieben:

>[...]
> Why FormClose doesn't close the form in presence of an error (handled by
> a try..finally) when writing the ini file?
> Launching from command line, you have the same behavior, and an
> additional information when you select Cancel:
>
> WARNING: TLCLComponent.Destroy with LCLRefCount>0. Hint: Maybe the component
> is processing an event?
>
>
> Try..except situation, from IDE and Debugger.
> Press the Close button. Debugger Notification. Pressing Continue my
> message dialog is shown. Pressing OK on my dialog the form is closed and
> the program is terminated.
> Launching from command line, no console messages.
>
> My conclusion is that one can't properly handle INI files with just a
> try..finally construct, as all examples show, because a possible error
> will propagate outside the construct, with unpredictable effects (in
> this case the FormClose procedure doesn't properly complete).

The LCL has a default exception handler, so that the application notifies the
user, that the application has a bug instead of simply crashing and vanishing
silently.
The programmr is reponsible to handle exceptions, show the user error messages
and give the user choices (e.g. ignore, retry).
BTW, the Ini.Free writes to disk, so it needs the try..except, the WriteValue
calls do not need the try..except.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Michael Van Canneyt


On Tue, 12 Feb 2013, Mattias Gaertner wrote:

>
> Giuliano Colla <[hidden email]> hat am 12. Februar 2013 um 13:29
> geschrieben:
>> [...]
>> Why FormClose doesn't close the form in presence of an error (handled by
>> a try..finally) when writing the ini file?
>> Launching from command line, you have the same behavior, and an
>> additional information when you select Cancel:
>>
>> WARNING: TLCLComponent.Destroy with LCLRefCount>0. Hint: Maybe the component
>> is processing an event?
>>
>>
>> Try..except situation, from IDE and Debugger.
>> Press the Close button. Debugger Notification. Pressing Continue my
>> message dialog is shown. Pressing OK on my dialog the form is closed and
>> the program is terminated.
>> Launching from command line, no console messages.
>>
>> My conclusion is that one can't properly handle INI files with just a
>> try..finally construct, as all examples show, because a possible error
>> will propagate outside the construct, with unpredictable effects (in
>> this case the FormClose procedure doesn't properly complete).
>
> The LCL has a default exception handler, so that the application notifies the
> user, that the application has a bug instead of simply crashing and vanishing
> silently.
> The programmr is reponsible to handle exceptions, show the user error messages
> and give the user choices (e.g. ignore, retry).
> BTW, the Ini.Free writes to disk, so it needs the try..except, the WriteValue
> calls do not need the try..except.

That depends.
if you disabled write caching, every write call will update the file.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Mark Morgan Lloyd-5
In reply to this post by Giuliano Colla
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.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla
In reply to this post by Mattias Gaertner
On 02/12/2013 01:58 PM, Mattias Gaertner wrote:
> The LCL has a default exception handler, so that the application
> notifies the user, that the application has a bug instead of simply
> crashing and vanishing silently. The programmr is reponsible to handle
> exceptions, show the user error messages and give the user choices
> (e.g. ignore, retry).
That's what I was relying on. There's nothing the application can do if
a user has write-protected the configuration files, or if there's a disk
error while writing (I didn't think of a non existing .config/, because
I've always found it there, before the last episode).
So I was just happy with a system error, which in this case fails to show.

As an additional information:
in FormClose

ini := TIniFile.Create(BadAppConfigFileName);
try
   ini.WriteWhatever(...
   ...
except
   on E: Exception do Application.ShowException(E);
end;


shows the error only on the console, but no visual dialog.
While

   on E: Exception do MessageDlg(E.Message,mtError,[mbOk],0);

shows a proper message dialog.

Maybe this discussion should be moved to Lazarus list?

Giuliano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla
In reply to this post by Mark Morgan Lloyd-5
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internallinker problem)

wkitty42
In reply to this post by el_es
On 2/12/2013 06:18, Lukasz Sokol wrote:
> On 11/02/2013 23:19, Gerhard Scholz wrote:
>> I switched to AVAST free Antivirus now, the problem does not occur here.
>>
>> This is not a pascal question, but maybe can give me a hint if AVAST is good
>> or which software is more recommendable.
>> (I do not really trust the tests I find in the internet because I do not know
>> who pays them)
>
> I found myself recently quite comfortable using ZoneAlarm.

apples and oranges... one is an anti-virus product and the other a firewall ;)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internallinker problem)

Sven Barth-2
On 12.02.2013 19:10, waldo kitty wrote:

> On 2/12/2013 06:18, Lukasz Sokol wrote:
>> On 11/02/2013 23:19, Gerhard Scholz wrote:
>>> I switched to AVAST free Antivirus now, the problem does not occur here.
>>>
>>> This is not a pascal question, but maybe can give me a hint if AVAST
>>> is good
>>> or which software is more recommendable.
>>> (I do not really trust the tests I find in the internet because I do
>>> not know
>>> who pays them)
>>
>> I found myself recently quite comfortable using ZoneAlarm.
>
> apples and oranges... one is an anti-virus product and the other a
> firewall ;)

No one forbids those growing apple trees to grow orange trees as well:
http://www.zonealarm.com/security/en-us/zonealarm-free-antivirus-firewall.htm

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internallinker problem)

Ralf A. Quint
At 01:31 PM 2/12/2013, Sven Barth wrote:

>On 12.02.2013 19:10, waldo kitty wrote:
>>On 2/12/2013 06:18, Lukasz Sokol wrote:
>>>On 11/02/2013 23:19, Gerhard Scholz wrote:
>>>>I switched to AVAST free Antivirus now, the problem does not occur here.
>>>>
>>>>This is not a pascal question, but maybe can give me a hint if AVAST
>>>>is good
>>>>or which software is more recommendable.
>>>>(I do not really trust the tests I find in the internet because I do
>>>>not know
>>>>who pays them)
>>>
>>>I found myself recently quite comfortable using ZoneAlarm.
>>
>>apples and oranges... one is an anti-virus product and the other a
>>firewall ;)
>
>No one forbids those growing apple trees to grow orange trees as
>well:
>http://www.zonealarm.com/security/en-us/zonealarm-free-antivirus-firewall.htm

Does it brew coffee and vacuum the floor as well? >:-}

Ralf ;-)
   

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internallinker problem)

Sven Barth-2
On 12.02.2013 20:45, Ralf A. Quint wrote:

> At 01:31 PM 2/12/2013, Sven Barth wrote:
>> On 12.02.2013 19:10, waldo kitty wrote:
>>> On 2/12/2013 06:18, Lukasz Sokol wrote:
>>>> On 11/02/2013 23:19, Gerhard Scholz wrote:
>>>>> I switched to AVAST free Antivirus now, the problem does not occur
>>>>> here.
>>>>>
>>>>> This is not a pascal question, but maybe can give me a hint if AVAST
>>>>> is good
>>>>> or which software is more recommendable.
>>>>> (I do not really trust the tests I find in the internet because I do
>>>>> not know
>>>>> who pays them)
>>>>
>>>> I found myself recently quite comfortable using ZoneAlarm.
>>>
>>> apples and oranges... one is an anti-virus product and the other a
>>> firewall ;)
>>
>> No one forbids those growing apple trees to grow orange trees as well:
>> http://www.zonealarm.com/security/en-us/zonealarm-free-antivirus-firewall.htm
>>
>
> Does it brew coffee and vacuum the floor as well? >:-}

I so hope not...

Note: If anyone wants to answer to this "anti virus" thread that was off
topic to begin with, we should move over to fpc-other.

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Michael Müller-10
In reply to this post by Giuliano Colla

Am 12.02.2013 um 13:29 schrieb Giuliano Colla:

> I've made some further experiments with my minimal test.
> Test form is just a Form with a Close button (BitBtn Kind=bkClose).
> The full code is the following:
>
> unit uinitfile;
>
> {$mode objfpc}{$H+}
>
> interface
>
> uses
>  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, Buttons,IniFiles;
>
> type
>
>  { TForm1 }
>
>  TForm1 = class(TForm)
>    BitBtn1: TBitBtn;
>    procedure FormClose(Sender: TObject; var CloseAction: TCloseAction);
>    procedure FormCreate(Sender: TObject);
>  private
>    { private declarations }
>  public
>    { public declarations }
>  end;
>
> var
>  Form1: TForm1;
>  ini: TIniFile;
>  AppConfigFileName: string;
>  SomeData: boolean;
>  SomeOtherData: boolean;
> implementation
>
> {$R *.lfm}
>
> { TForm1 }
>
> procedure TForm1.FormCreate(Sender: TObject);
> begin
> AppConfigFileName:= '/not/existing/path/inifile.cfg';
> ini := TIniFile.Create(AppConfigFileName);
> try
>   SomeData:= ini.ReadBool('Section','Val',true);
>   SomeOtherData:= ini.ReadBool('Section','Val1',true);
> finally
>   ini.Free;
> end;
> end;
>
> procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
> begin
>  ini:= TIniFile.Create(AppConfigFileName);
> {$DEFINE Finally}
> {$IFDEF Finally}
>  try
>    ini.WriteBool('Section','Val',SomeData);
>    ini.WriteBool('Section','Val1',SomeOtherData);
>  finally
>    ini.Free;
>  end;
> {$ELSE}
>  try
>    ini.WriteBool('Section','Val',SomeData);
>    ini.WriteBool('Section','Val1',SomeOtherData);
>  except
>    MessageDlg('Error while writing '+AppConfigFileName,mtError,[mbOK],0);
>  end;
>  ini.Free;
> {$ENDIF}
> end;
>
> end.

I'm not sure if somebody else mentioned this already but I have the feeling that Giuliano thinks that he has to decide to use try-finally OR try-except but there are situations where you need both. One of the criteria is if the object is local or global since for a global object it is likely that you place the .Free (or for a global object better FreeAndNil()) into a destructor or finalization section (which means that you have to stop the program in case of an error and not continue showing just a dialog) so you'll need only the try-except if you want to catch the exception. In case of a local object you'll ALWAYS have the lines

Obj := Class.Create;
try
  // do some code
finally
  Obj.Free;
end;

otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put try-except extra around try-finally so you'll end up with

Obj := Class.Create;
try
  try
    // do some code
  finally
    Obj.Free;
  end;
except
  writeln('We have a problem);
  halt the program or reraise the exception or raise a new one
end;

Regards

Michael_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Mark Morgan Lloyd-5
Michael Müller wrote:

> I'm not sure if somebody else mentioned this already but I have the feeling that Giuliano thinks that he has to decide to use try-finally OR try-except but there are situations where you need both. One of the criteria is if the object is local or global since for a global object it is likely that you place the .Free (or for a global object better FreeAndNil()) into a destructor or finalization section (which means that you have to stop the program in case of an error and not continue showing just a dialog) so you'll need only the try-except if you want to catch the exception. In case of a local object you'll ALWAYS have the lines

> Obj := Class.Create;
> try
>   try
>     // do some code
>   finally
>     Obj.Free;
>   end;
> except
>   writeln('We have a problem);
>   halt the program or reraise the exception or raise a new one
> end;

I tried to make that point but I'm not sure the message reached its mark.

It's possibly unfortunate that Borland chose to use "try" for both
constructs, rather than having distinct try-except-end and
start-finally-end forms.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

el_es
In reply to this post by Michael Müller-10
On 13/02/2013 07:34, Michael Müller wrote:

> I'm not sure if somebody else mentioned this already but I have the feeling that Giuliano thinks that he has to decide to use try-finally OR try-except but there are situations where you need both. One of the criteria is if the object is local or global since for a global object it is likely that you place the .Free (or for a global object better FreeAndNil()) into a destructor or finalization section (which means that you have to stop the program in case of an error and not continue showing just a dialog) so you'll need only the try-except if you want to catch the exception. In case of a local object you'll ALWAYS have the lines
>
> Obj := Class.Create;
> try
>   // do some code
> finally
>   Obj.Free;
> end;
>
> otherwise you'll end up with memory leaks.
> If you want to catch the exception in this situation you'll put try-except extra around try-finally so you'll end up with
>
> Obj := Class.Create;
> try
>   try
>     // do some code
>   finally
>     Obj.Free;
>   end;
> except
>   writeln('We have a problem);
>   halt the program or reraise the exception or raise a new one
> end;
>
> Regards
>
To developers:
How would a generalized/packed construct like

try
[code block]
finally
[code block]
except
[code block]
end;

(in other words: a try-*-end construct where * can be 'finally', or 'except', or BOTH.)

fit into Pascal philosophy?
Advantages is mainly:
- one less indent level ('oh, I need try-except around all THAT, bugger.') to care about;
  (yeah, even with all the good tools to manage the code, it stings, that the two
   have to be separately declared and one needs to remember that...)

Would it be very complicated?

Lukasz

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internallinker problem)

el_es
In reply to this post by Sven Barth-2
On 12/02/2013 21:45, Sven Barth wrote:

>
> Note: If anyone wants to answer to this "anti virus" thread that was
> off topic to begin with, we should move over to fpc-other.
>
> Regards, Sven

My apologies, I should have added [OT] to my reply.

Lukasz

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12345