On 18/02/2013 18:53, DaWorm wrote:
If this is what is really desired, is this a good construct?
try ... except ... finally ... except ... end;
I don't care for the meaning of except looking to be contextual,
but is it really? Reading that, to me it looks mostly predictable
how the
On 18.02.2013 19:53, DaWorm wrote:
On Mon, Feb 18, 2013 at 8:02 AM, Lukasz Sokol el.es...@gmail.com
mailto:el.es...@gmail.com wrote:
Maybe he one and true answer for all of the above would be to have:
try vs try
try except
try
On 14/02/2013 13:58, Giuliano Colla wrote:
It depends on what one tries to do in the try.. clause, on which
errors one choses to deal with on the except clause, and the
likelihood of recoverable errors in the finally clause. Allowing both
constructs, (try..except..finally and
On Mon, Feb 18, 2013 at 8:02 AM, Lukasz Sokol el.es...@gmail.com wrote:
Maybe he one and true answer for all of the above would be to have:
try vs try
try except
try finally
except except
end;
On 13/02/2013 16:50, Giuliano Colla wrote:
IMHO the try..except..finally construct should provide exactly the same
functionality as a nested
try
try
[code]
except
[code]
end;
finally
[code]
end;
i.e. it should be executed whatever happened in the sections between try and
Lukasz Sokol ha scritto:
It is subtle, I agree, but in
try
try
[code]
finally
[code]
end;
except
[code]
end; (my version)
I can catch the errors of either normal and finally code;
I assume that try...finally...end is the more important; it is try...finally..
end that has to go
Sven Barth ha scritto:
I don't see the point of a else or nonexcept branch. If I want
code to be executed in the case that no exception happened (e.g. a
Commit for a database transaction) then I put in the block started by
the try... One might argue that an additional branch would increase
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
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
Lukasz Sokol wrote:
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
On 13.02.2013 09:58, Mark Morgan Lloyd wrote:
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
On 13.02.2013 10:11, Lukasz Sokol wrote:
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
On 13/02/2013 09:39, Mark Morgan Lloyd wrote:
Lukasz Sokol wrote:
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
On 13/02/2013 11:01, Sven Barth wrote:
On 13.02.2013 10:11, Lukasz Sokol wrote:
[...]
To developers: How would a generalized/packed construct like
try [code block] finally [code block] except [code block] end;
or what about
try [code block] except [code block] finally [code block] end;
On 13/02/2013 11:01, Sven Barth wrote:
Keep this FAQ entry in mind when suggesting features:
http://www.freepascal.org/faq.var#extensionselect
(Note: I personally would have nothing against such a feature, but
the details need to be defined!)
Well I guess unless someone is ready to have
On 13.02.2013 12:41, Lukasz Sokol wrote:
On 13/02/2013 11:01, Sven Barth wrote:
Keep this FAQ entry in mind when suggesting features:
http://www.freepascal.org/faq.var#extensionselect
(Note: I personally would have nothing against such a feature, but
the details need to be defined!)
Well I
On 13/02/2013 12:31, Sven Barth wrote:
On 13.02.2013 12:41, Lukasz Sokol wrote:
[...]
But it's not just 'shorter', it's relatively 'safer' too, and
doesn't forbid anybody from using traditional constructs either, at
all, if they wish so/need so.
That's for example a reason that speaks for
On 13.02.2013 13:44, Lukasz Sokol wrote:
On 13/02/2013 12:31, Sven Barth wrote:
On 13.02.2013 12:41, Lukasz Sokol wrote:
[...]
But it's not just 'shorter', it's relatively 'safer' too, and
doesn't forbid anybody from using traditional constructs either, at
all, if they wish so/need so.
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
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
On Wed, 13 Feb 2013, Giuliano Colla wrote:
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
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
On 13/02/2013 13:14, Michael Van Canneyt wrote:
I see no problem in adding finally, if you define carefully when it is
executed.
Michael.
I second that, we don't need no pythonisms here ;) (or is it pythonosis?)
I'd rephrase what I discussed with Sven Barth:
this construct (the
Michael Van Canneyt ha scritto:
On Wed, 13 Feb 2013, Giuliano Colla wrote:
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
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
Lukasz Sokol ha scritto:
On 13/02/2013 13:14, Michael Van Canneyt wrote:
I'd rephrase what I discussed with Sven Barth:
this construct (the packed try.(1).finally.(2).except.(3).end;) - a
packed/condensed version -
I would be in favor of try..except..finally, as opposed to
On 13.02.2013 17:50, Giuliano Colla wrote:
Python provides the following:
try
[code block]
except
[code block]
else
[code block]
finally
[code block]
end;
which can be used in any reasonable combination: just try..except,
just try..finally just try..except..else etc.
The except..else is a very
On 13.02.2013 18:07, Giuliano Colla wrote:
Lukasz Sokol ha scritto:
On 13/02/2013 13:14, Michael Van Canneyt wrote:
I'd rephrase what I discussed with Sven Barth:
this construct (the packed try.(1).finally.(2).except.(3).end;) - a
packed/condensed version -
I would be in favor of
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
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
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
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
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
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.
Giuliano Colla giuliano.co...@fastwebnet.it 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
On Tue, 12 Feb 2013, Mattias Gaertner wrote:
Giuliano Colla giuliano.co...@fastwebnet.it 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
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
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
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
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,
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
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
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.
Giuliano Colla wrote:
However, what I've learned from this episode is that while attempting to
save configuration data using TINIFile on program termination you should
never use a try..finally construct, as it's suggested everywhere, but
rather a try..except (or both). Otherwise you'll never
Il 11/02/2013 12:40, Mark Morgan Lloyd ha scritto:
Giuliano Colla wrote:
However, what I've learned from this episode is that while attempting
to save configuration data using TINIFile on program termination you
should never use a try..finally construct, as it's suggested
everywhere, but
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
On 2013-02-11 11:29, Giuliano Colla wrote:
This is true only if you invoke the program from command line, which is
something the end user will never do.
Wrong. This is something you are doing wrong in your GUI application
then. I have loads of fpGUI 'gui' applications, that report
On Mon, 11 Feb 2013, Giuliano Colla wrote:
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
Giuliano Colla wrote:
Il 11/02/2013 12:40, Mark Morgan Lloyd ha scritto:
Giuliano Colla wrote:
However, what I've learned from this episode is that while attempting
to save configuration data using TINIFile on program termination you
should never use a try..finally construct, as it's
On 02/11/2013 01:57 PM, Michael Van Canneyt wrote:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
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.
On 02/11/2013 01:34 PM, Graeme Geldenhuys wrote:
On 2013-02-11 11:29, Giuliano Colla wrote:
This is true only if you invoke the program from command line, which is
something the end user will never do.
Wrong. This is something you are doing wrong in your GUI application
then. I have loads of
Lost in the shuffle, wasn't this originally found in Lazarus? Sounds like
a bug report for incorrect handling of INI files when the config directory
is missing needs to be filed in their bug tracker.
Jeff.
___
fpc-pascal maillist -
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.
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
On Mon, 11 Feb 2013 17:02:39 +0100
Sven Barth pascaldra...@googlemail.com 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
On 11.02.2013 17:16, Mattias Gaertner wrote:
On Mon, 11 Feb 2013 17:02:39 +0100
Sven Barth pascaldra...@googlemail.com 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
On 02/11/2013 04:45 PM, DaWorm wrote:
Lost in the shuffle, wasn't this originally found in Lazarus? Sounds
like a bug report for incorrect handling of INI files when the config
directory is missing needs to be filed in their bug tracker.
INI files and related stuff are part of the fcl
On Mon, Feb 11, 2013 at 1:48 PM, Giuliano Colla
giuliano.co...@fastwebnet.it wrote:
On 02/11/2013 04:45 PM, DaWorm wrote:
Lost in the shuffle, wasn't this originally found in Lazarus? Sounds
like a bug report for incorrect handling of INI files when the config
directory is missing needs to
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
On 11.02.2013 21:10, Giuliano Colla wrote:
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
On 2013-02-09 13:56, Bart wrote:
While this can easily be implemented without breaking existing code,
this still does not solve the original problem.
If creating the directory fails, the function does not return an
errorcode, unless we decide to let it raise an exception in this
case..
On 02/10/2013 12:43 PM, Graeme Geldenhuys wrote:
On 2013-02-09 13:56, Bart wrote:
While this can easily be implemented without breaking existing code,
this still does not solve the original problem.
If creating the directory fails, the function does not return an
errorcode, unless we decide to
On Mon, 11 Feb 2013 00:13:00 +0100
Giuliano Colla giuliano.co...@fastwebnet.it 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.
I get an exception in this case:
On Sat, 9 Feb 2013, Reinier Olislagers wrote:
On 9-2-2013 1:49, Giuliano Colla wrote:
It turned out that the reason was simply that the default AppConfigDir
(~/.config/ ) wasn't there, and therefore in the two usual lines
AppConfigFileName:= GetAppConfigFile(False);
ini :=
On 9-2-2013 10:25, Michael Van Canneyt wrote:
On Sat, 9 Feb 2013, Reinier Olislagers wrote:
On 9-2-2013 1:49, Giuliano Colla wrote:
It turned out that the reason was simply that the default AppConfigDir
(~/.config/ ) wasn't there, and therefore in the two usual lines
AppConfigFileName:=
Il 09/02/2013 10:25, Michael Van Canneyt ha scritto:
On Sat, 9 Feb 2013, Reinier Olislagers wrote:
On 9-2-2013 1:49, Giuliano Colla wrote:
It turned out that the reason was simply that the default AppConfigDir
(~/.config/ ) wasn't there, and therefore in the two usual lines
On Sat, 9 Feb 2013, Giuliano Colla wrote:
Il 09/02/2013 10:25, Michael Van Canneyt ha scritto:
On Sat, 9 Feb 2013, Reinier Olislagers wrote:
On 9-2-2013 1:49, Giuliano Colla wrote:
It turned out that the reason was simply that the default AppConfigDir
(~/.config/ ) wasn't there, and
On 2/9/13, Michael Van Canneyt mich...@freepascal.org wrote:
Like I said, we can imagine a parameter 'AllowCreate' or 'ForceCreate'.
GetAppConfigDir(Global : Boolean: ForceCreate: Booelan = false) : String;
While this can easily be implemented without breaking existing code,
this still does
On Sat, 9 Feb 2013, Bart wrote:
On 2/9/13, Michael Van Canneyt mich...@freepascal.org wrote:
Like I said, we can imagine a parameter 'AllowCreate' or 'ForceCreate'.
GetAppConfigDir(Global : Boolean: ForceCreate: Booelan = false) : String;
While this can easily be implemented without
On 2/9/13, Michael Van Canneyt mich...@freepascal.org wrote:
If creating the directory fails, the function does not return an
errorcode, unless we decide to let it raise an exception in this
case..
There is only one way:
if the ForceCreate is implemented and if creation fails, an exception
On Sat, 9 Feb 2013, Bart wrote:
On 2/9/13, Michael Van Canneyt mich...@freepascal.org wrote:
If creating the directory fails, the function does not return an
errorcode, unless we decide to let it raise an exception in this
case..
There is only one way:
if the ForceCreate is implemented
On 02/09/2013 04:19 PM, Michael Van Canneyt wrote:
On Sat, 9 Feb 2013, Bart wrote:
And in this case the OP still needs to do an extra check
(try..except), so basically this does not solve his problem because
it is unsolvable without the programmer checking/validating what
GetAppConfigDir
On 9-2-2013 1:49, Giuliano Colla wrote:
It turned out that the reason was simply that the default AppConfigDir
(~/.config/ ) wasn't there, and therefore in the two usual lines
AppConfigFileName:= GetAppConfigFile(False);
ini := TIniFile.Create(AppConfigFileName);
the second line was
70 matches
Mail list logo
