On 18.02.2013 19:53, DaWorm wrote:
On Mon, Feb 18, 2013 at 8:02 AM, Lukasz Sokol 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 finally
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
> ho
On Mon, Feb 18, 2013 at 8:02 AM, Lukasz Sokol 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;end;
> final
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 try..finally..
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 increas
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 withou
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 betw
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 try..except
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
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
try..finally..
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 ha
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 construc
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 OR
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 you
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.
That'
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 spea
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 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
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 bl
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 BOT
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: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 the
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 les
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
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 globa
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, SysU
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 catc
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 an
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
On Tue, 12 Feb 2013, Mattias Gaertner wrote:
Giuliano Colla 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
Giuliano Colla 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 Ca
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.
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 wit
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 writ
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'
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 For
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 directo
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 prop
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 F
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
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 libra
On 11.02.2013 17:16, Mattias Gaertner wrote:
On Mon, 11 Feb 2013 17:02:39 +0100
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 :-)
An
On Mon, 11 Feb 2013 17:02:39 +0100
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 docume
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 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.
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 - fpc-pascal@lists.fr
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 f
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.
Th
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 suggeste
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 excep
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 excepti
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 e
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 excep
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 rath
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 b
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.
T
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 fail
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 provi
On Mon, 11 Feb 2013 00:13:00 +0100
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.
I get an exception in this case:
inifile:=TIniFile.Create('/does/not/exist/bla
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 l
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/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 di
On Sat, 9 Feb 2013, Bart wrote:
On 2/9/13, Michael Van Canneyt 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,
On 2/9/13, Michael Van Canneyt 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
> will be rai
On Sat, 9 Feb 2013, Bart wrote:
On 2/9/13, Michael Van Canneyt 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,
thi
On 2/9/13, Michael Van Canneyt 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 not solve the original p
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 ther
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
AppConfigFileNam
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
>>>
>>> AppConfigF
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 := TIniFile.Create(Ap
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
71 matches
Mail list logo
