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.

DaWorm
On Mon, Feb 18, 2013 at 8:02 AM, Lukasz Sokol <[hidden email]> 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;
  finally
  end;
except
end;

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

I haven't actually tried this, but what would this do?

try
  try
  except
  end;
finally
  try
  except
  end;
end;

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 logic would have to work.  I guess the only question is whether the finally code is executed if the try code has an exception.  If this isn't desired, could a "break" be used in the first except to cause the finally to be skipped?

Jeff.

_______________________________________________
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 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 logic would have to work.  I guess the only question is
> whether the finally code is executed if the try code has an
> exception.  If this isn't desired, could a "break" be used in the
> first except to cause the finally to be skipped?
>

Does "break" do it in traditional try..finally..end?
This new construct shall be no different.

That's actually why I opt for just try..finally...except..end; too -
because an exception in the 'finally' section, if it was the outer,
could have unpredictable consequences; with 'except' being outer,
at least your program will have a chance to still run and exit
(more or less) gracefully.

Lukasz
> Jeff.
>

_______________________________________________
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 DaWorm
On 18.02.2013 19:53, DaWorm wrote:

> On Mon, Feb 18, 2013 at 8:02 AM, Lukasz Sokol <[hidden email]
> <mailto:[hidden email]>> 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;
>        finally
>        end;
>     except
>     end;
>
>     so with except being optionally allowed either side of 'finally' ?
>
> I haven't actually tried this, but what would this do?
>
> try
>    try
>    except
>    end;
> finally
>    try
>    except
>    end;
> end;
>
> If this is what is really desired, is this a good construct?
>
> try
>    ...
> except
>    ...
> finally
>    ...
> except
>    ...
> end;
>

The idea for the construct is to replace (if I take your last example)
the following construct:

=== example begin ===

try
   try
     try

     except

     end;
   finally

   end;
except

end;

=== example end ===

The variant

=== example begin ===

try

finally

except

end;

=== example end ===

would replace

=== example begin ===

try
   try

   finally

   end;
except

end;

=== example end ===

and

=== example begin ===

try

except

finally

end;

=== example end ===

would replace

=== example begin ===

try
   try

   except

   end;
finally

end;

=== example end ===

These are the most common usages of nested try...finally/except blocks
and thus can increase the readability. Thus no change in semantics, only
in "formatting".

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