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

I think this complicates things unduly. As it is case-else and then-else
are about the only places where there is this sort of composite block,
and finally-except-end is even uglier since parts of all three blocks
may be executed.

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

Sven Barth-2
In reply to this post by Mark Morgan Lloyd-5
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 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.
>

Other languages did the same, so I don't see the problem here...

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.

Sven Barth-2
In reply to this post by el_es
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 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;

or what about

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

In any case the semantics need to be defined correctly. E.g. in the
first case what happens if an exception is raised inside the "finally"
block? In the second case what happens if an exception is raised inside
the "except" block? Do they work like nested "try try except end finally
end" or "try try finally end except end" blocks or do they have the same
rules?

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

>
> (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?

I don't know how complicated it would be (we now also need to take into
account Win64 SEH and possibly in the future also Win32 and WinCE SEH),
but it should at least be doable...

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.

el_es
In reply to this post by Mark Morgan Lloyd-5
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 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...)
>
> I think this complicates things unduly. As it is case-else and
> then-else are about the only places where there is this sort of
> composite block, and finally-except-end is even uglier since parts of
> all three blocks may be executed.
>

With the traditional construct there could be another place that
poses a potential pitfall:

[use fixed width font to see below comfortably]

try vs try
  try  [...]
    [...] finally
  finally  [...]
    [...] except
  end;  [...]
  //(*1*) end;
except
  [...]
end;

Using the composite one, protects the user of this construct from putting code into *1* place
where it may not be executed if exception happens in the try..finally block;

I'm not saying, this is not sometimes that one wants, but (at least in my case, YMMV)
putting code in *1 is a result of a thinko/PEBKAC. There, this I think is another (better?)
argument in favor of composite try...finally...except...end;

I still think the latter (single-level, composite) is nice to have.
And acknowledges that the two are in effect used together most of the time.

And lets one to easily add a 'finally' or 'except' section if need arises, without
loosing any code to *1* black hole.

Regards,
Lukasz

_______________________________________________
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 Sven Barth-2
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;
>
> In any case the semantics need to be defined correctly. E.g. in the
> first case what happens if an exception is raised inside the
> "finally" block? In the second case what happens if an exception is
> raised inside the "except" block? Do they work like nested "try try
> except end finally end" or "try try finally end except end" blocks or
> do they have the same rules?

I'd imagine it should work exactly like try try ... finally ... end; except ... end;
so if exception happens in 'finally' block, 'except' is executed,
if no exception happens anywhere, only 'finally' happens.

>
> Keep this FAQ entry in mind when suggesting features:
> http://www.freepascal.org/faq.var#extensionselect
>
Nice, thanks!

> (Note: I personally would have nothing against such a feature, but
> the details need to be defined!)
>
>>
>> (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?
>
> I don't know how complicated it would be (we now also need to take
> into account Win64 SEH and possibly in the future also Win32 and
> WinCE SEH), but it should at least be doable...
>
> Regards, Sven
>

I was imagining something in or just before the parser, detecting the 'composite'
construct and 'mechanically' (string for string even) substituting it for two-level
traditional, putting the 3 code blocks into the proper places.
No ifs, no buts, same semantics, just flattened.
Write once, compile everywhere ;) Unfortunately I don't have
enough compiler knowledge to even imagine where this could be happening.

That would have all cases covered then...?

Lukasz

_______________________________________________
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 Sven Barth-2
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 a precedent of relaxing
rule 2 here 'Anything that is only a shorter notation does not apply ...'
this won't happen :(

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.

Lukasz





_______________________________________________
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
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 guess unless someone is ready to have a precedent of relaxing
> rule 2 here 'Anything that is only a shorter notation does not apply ...'
> this won't happen :(
>

Precedent: case of String

If the other reasons are compelling enough or someone even provides a
patch for the feature I personally see no problem. Of course the
opinions of the other core developers matter as well...

> 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 the feature.

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. [OT]

el_es
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 the feature.
>
> Regards, Sven

Thanks, your acceptance made me shed a tear of joy and made my day brighter :)

Lukasz

_______________________________________________
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. [OT]

Sven Barth-2
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's for example a reason that speaks for the feature.
>>
>> Regards, Sven
>
> Thanks, your acceptance made me shed a tear of joy and made my day brighter :)

It's mostly because I want that feature for a long time myself. :)

You'll nevertheless have to convince at least a few more core devs that
this feature would be useful or/and implement it yourself... [mostly
because I'm currently busy with other projects, either FPC related or
not ^^]

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.

Giuliano Colla
In reply to this post by Sven Barth-2
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 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;
>
> or what about
>
> try
> [code block]
> except
> [code block]
> finally
> [code block]
> end;
>

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 useful construct, because it provides a path
to a code block to execute only if there were no previous errors.
This wouldn't break any existing applications, just add very useful
features.

What fpc developers think about that?

Giuliano

--
Giuliano Colla

Before activating the tongue, make sure that the brain is connected
(anonymous)
_______________________________________________
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 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
>>>> 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;
>>
>> or what about
>>
>> try
>> [code block]
>> except
>> [code block]
>> finally
>> [code block]
>> end;
>>
>
> 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 useful construct, because it provides a path to a
> code block to execute only if there were no previous errors.
> This wouldn't break any existing applications, just add very useful features.
>
> What fpc developers think about that?
"Else" is used in Except already to select between various classes:

try
   ..
except
   on E : MyType do
     begin
     end
else
   // exception is not MyType
end;

so that is a problem.

I see no problem in adding finally, if you define carefully when it is executed.

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.

el_es
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 packed try.(1).finally.(2).except.(3).end;) - a packed/condensed version -

- should be semantically EXACT to try.(HOLE1).try.(1).finally.(2).end;.(HOLE2).except.(3).end;

  Legend:
  (1,2,3): code blocks
  (HOLE1) possibility for the try..finally..end block to be skipped if exception happens here
  (HOLE2) possibility for code to be skipped if exception happens in the try...finally...end; block

- except, it will not have the HOLEs. Because [maybe some statistics needed here] this is
probably the main (most advocated ?) use of them both at the same time.

- It shall allow any constructs that are allowed in traditional (1,2,3) code blocks to be
used exactly the same way with the same meaning.

The new way will:

-flatten the source code (one indent level less)
-shorten the source code (one 'try' and one 'end;' less)
-provide automatic protection from falling into the (HOLEs). (thinkos and PEBKACs protection)
 (this is most important here I think).

Note that I'm not advocating for this to replace the traditional constructs;
Also I accept, that HOLEs may be perfectly justified code. But if someone needs them, they probably
know what they are doing.

Hope this makes sense,
Lukasz


_______________________________________________
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 Michael Van Canneyt
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 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;
>>>
>>> or what about
>>>
>>> try
>>> [code block]
>>> except
>>> [code block]
>>> finally
>>> [code block]
>>> end;
>>>
>>
>> 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 useful construct, because it provides a
>> path to a code block to execute only if there were no previous errors.
>> This wouldn't break any existing applications, just add very useful
>> features.
>>
>> What fpc developers think about that?
>
> "Else" is used in Except already to select between various classes:
>
> try
>   ..
> except
>   on E : MyType do
>     begin
>     end
> else
>   // exception is not MyType
> end;
>
> so that is a problem.

I didn't think of that, because I never use it. It would be nice to use
it the other way, but I understand it would break existing code. A
different keyword like nonexcept?

>
> I see no problem in adding finally, if you define carefully when it is
> executed.

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 finally (except if somewhere there was an Application.terminate!).
Any exception not handled shoud be re-raised after the finally block has
been executed.
The advantage would be to get rid of one level of nesting, making the
code more readable and less error prone.
This would guarantee both proper error handling and freeing of global
resources, even in presence of errors.

Giuliano

--
Giuliano Colla

Before activating the tongue, make sure that the brain is connected
(anonymous)
_______________________________________________
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 el_es
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..except, because I believe it better to handle exceptions
before, and clean-up after. Exception handling doesn't consist only in
showing an error box, it may involve also providing a remedy to some
errors, and hopefully passing to finally a cleaner situation to handle.
I'm ready to change advise if proved wrong.

> - should be semantically EXACT to try.(HOLE1).try.(1).finally.(2).end;.(HOLE2).except.(3).end;
>
>   Legend:
>   (1,2,3): code blocks
>   (HOLE1) possibility for the try..finally..end block to be skipped if exception happens here
>   (HOLE2) possibility for code to be skipped if exception happens in the try...finally...end; block
>
> - except, it will not have the HOLEs. Because [maybe some statistics needed here] this is
> probably the main (most advocated ?) use of them both at the same time.
>
> - It shall allow any constructs that are allowed in traditional (1,2,3) code blocks to be
> used exactly the same way with the same meaning.
>
> The new way will:
>
> -flatten the source code (one indent level less)
> -shorten the source code (one 'try' and one 'end;' less)
> -provide automatic protection from falling into the (HOLEs). (thinkos and PEBKACs protection)
>  (this is most important here I think).
>
> Note that I'm not advocating for this to replace the traditional constructs;
> Also I accept, that HOLEs may be perfectly justified code. But if someone needs them, they probably
> know what they are doing.

If one is left free not to use the new construct, he can use the old
one, and put in as many holes as he want.
After all one is free to insert anywhere in the code a few assembler
lines and to break anything fpc developers had in mind..

Giuliano


--
Giuliano Colla

Before activating the tongue, make sure that the brain is connected
(anonymous)
_______________________________________________
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 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 useful construct, because it provides a
>>> path to a code block to execute only if there were no previous errors.
>>> This wouldn't break any existing applications, just add very useful
>>> features.
>>>
>>> What fpc developers think about that?
>>
>> "Else" is used in Except already to select between various classes:
>>
>> try
>>   ..
>> except
>>   on E : MyType do
>>     begin
>>     end
>> else
>>   // exception is not MyType
>> end;
>>
>> so that is a problem.
>
> I didn't think of that, because I never use it. It would be nice to use
> it the other way, but I understand it would break existing code. A
> different keyword like nonexcept?
>

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 readability,
but I personally don't see a real use for it...

>>
>> I see no problem in adding finally, if you define carefully when it is
>> executed.
>
> 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 finally (except if somewhere there was an Application.terminate!).

Application.Terminate is not special. It merely sets a "FTerminated" to
True which will trigger a leave of the application main loop once the
event handler returns. The only function that would be special in that
regard is "Halt", but that already works that way that any handlers are
skipped.

> Any exception not handled shoud be re-raised after the finally block has
> been executed.
> The advantage would be to get rid of one level of nesting, making the
> code more readable and less error prone.
> This would guarantee both proper error handling and freeing of global
> resources, even in presence of errors.

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.

Sven Barth-2
In reply to this post by Giuliano Colla
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..finally, as opposed to
> try..finally..except, because I believe it better to handle exceptions
> before, and clean-up after. Exception handling doesn't consist only in
> showing an error box, it may involve also providing a remedy to some
> errors, and hopefully passing to finally a cleaner situation to handle.
> I'm ready to change advise if proved wrong.

As the proposed construct is a "mere" syntactic sugar anyway I see no
problem in allowing both cases (after all you can do both ways with the
original constructs as well)...

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.

el_es
In reply to this post by Giuliano Colla
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 finally (except if somewhere there was an Application.terminate!). Any exception not handled shoud be re-raised after the finally block has been executed.
> The advantage would be to get rid of one level of nesting, making the code more readable and less error prone.
> This would guarantee both proper error handling and freeing of global resources, even in presence of errors.
>

> Giuliano
>

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 without errors,
or else one will be reported; if no exception happens, except is omitted; the except section in this case, can
catch anything and its job is to decide whether to allow further execution, show/log a message or bail out.
(also AFAICS this way it is recommended to be used in most snippets)

In your case (try..finally...end being the outer), what if it may not be possible to free the global resources
(e.g. if you .Created a TStringList, and in finally you want to .Free it, but say, its pointer got corrupted or
something free'd it already, and you can't - you'll get an AV which you'd have to catch in another try..except..end
to properly show user a message? Or if something else that has to be done in finally section, throws?)

Kind Regards,
Lukasz


_______________________________________________
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
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 without errors,
> or else one will be reported; if no exception happens, except is omitted; the except section in this case, can
> catch anything and its job is to decide whether to allow further execution, show/log a message or bail out.
> (also AFAICS this way it is recommended to be used in most snippets)
>
> In your case (try..finally...end being the outer), what if it may not be possible to free the global resources
> (e.g. if you .Created a TStringList, and in finally you want to .Free it, but say, its pointer got corrupted or
> something free'd it already, and you can't - you'll get an AV which you'd have to catch in another try..except..end
> to properly show user a message? Or if something else that has to be done in finally section, throws?)
>
>  
The purpose of the try..except construct is to allow the developer to
put some remedy in case of errors, instead of just aborting the program.
The purpose of the try..finally construct is to guarantee some actions
even if the program is going to be aborted.
The new constructs would provide both options at the same time. But I'm
afraid that there's not a "better solution" good for all situation. 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..except) as Sven suggested, would most likely cover a
broader range of cases.
Then, sometimes someone will still need nested try..whatever, to deal
with situations which do really require the HOLES you mentioned.

Giuliano

--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_______________________________________________
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
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
> readability, but I personally don't see a real use for it...
You're right. At first glance it appeared to me a good idea, but
actually it wouldn't provide anything useful.

--
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

_______________________________________________
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 Giuliano Colla
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..except) as Sven
> suggested, would most likely cover a broader range of cases. Then,
> sometimes someone will still need nested try..whatever, to deal with
> situations which do really require the HOLES you mentioned.

At first I thought, that having 2 versions of this construct, would be
overkill; and whether it is intuitive enough for everybody that the last
section will be the 'outside', it's hard to say without others input;

For myself, the more intuitive construct is, to do try, then finally,
if no exception anywhere then skip except, otherwise (whether it happened
in try or finally) execute the exception handling code. Which equals the tandem
construct with except on outside.

But now, I think it actually would be a good thing to have the other too;

Whether the order of the inside/outside sections should be selectable by order of
keywords in the flattened construct, is still debatable; I think if majority
agrees that this is intuitive enough,

Main reason is to close the HOLEs, secondary, flatten the code and shorten it down
even if only a bit.

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;
  finally
  end;
except
end;

so with except being optionally allowed either side of 'finally' ?

Lukasz
>
> Giuliano
>


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