[fpc-pascal] why isn't the 'exit' in the finally end clause executed?
Using fpc 3.0.4, Lazarus 2.0, the following simple program
program tryfinally;
begin
try
Writeln('before finally');
finally
Writeln('inside finally. Before Exit');
exit; //tryfinally.exe
before finally
inside finally. Before Exit
after try finally block
I have tried putting the try finally block inside a procedure, the same
happened.
program tryfinally;
procedure Test;
begin
try
Writeln('before finally');
finally
Writeln('inside finally. Before Exit');
exit;
end;
Writeln('after try finally block');
end;
begin
Test;
end.
Dennis
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Am 23.06.2019 um 00:50 schrieb Michael Van Canneyt: On Sat, 22 Jun 2019, Sven Barth via fpc-pascal wrote: The REst Module has the additional disadvantage that you must have an initial /REST/ or whatever part in your URL. With the dispatcher on a datamodule, you can skip this if so desired... Okay, independently of whether the REST module is the optimal solution or not, it should work, right? (and shouldn't the Wiki entry then mention the advantages/disadvantages of the two approaches? Cause when looking at the SQLDB REST module I thought "yay, less stuff to configure" and rolled with that) What exactly is less to configure ? :) Looking at the Wiki again I was fooled by the Datamodule having 8 bullet points, the SQLDBRestModule having 5, but the later simply shortening stuff with point five... So yeah... not really less to configure... My fault. ^^' Cause with the changes you committed the example provided with Lazarus still does not work (even if I change MyDispatcher.Active to False and MyDispatcher.BasePath to 'REST'). The error is always "INVALID RESOURCE" which means that ExtractRestResourceName returned an empty string (which is logical, cause there neither exists a route that sets 'resource' nor is HandleMetadataRequest ever called). Ah. Documentation issue. If you use a restmodule, then I expect the resource to be provided using ?resourceParam=Name, not in the URL. See function TSQLDBRestDispatcher.ExtractRestResourceName(IO: TRestIO): UTF8String; Ah! But that isn't mentioned in the Wiki, right? Cause the Wiki only mentioned the URL based stuff and thus I assumed the SQLDBRESTModule to behave the same... By the way: I sometimes get a EStreamError *after* all data had been sent to the client. I have not yet found a reproducible way for this... We can of course change that to try and look in the URL as well using GetNextPathInfo on the request if the routes are not registered, that should work. But then it needs to be done early on in the HandleRequest because the rdoInConnection needs to be observed, so the path can be read only once. It will probably require a new rdoUseRequestPathInfo, which could be set by the restmodule... I will look at this. Would at least be nice to not have to care how one needs to call the server side... - localhost:8080/metadata works - localhost:8080/users returns "INVALID RESOURCE" Because it has rdoConnectionInURL set, and so you must do localhost:8080/expenses/users Ahh! Hadn't seen that this option is active... Okay, then it indeed works as expected, both with and without rdoConnectionInURL. By the way: I noticed a slight annoyance, but I don't know whether one can really do something about that: When I set rdoConnectionInURL to False inside the object inspector it turns on again, because rdoConnectionResource is set. Took me a moment to look at the source code to see that I need to disable rdoConnectionResource first. Don't know what a better solution would be... Further thing I noticed when testing BufClient and CSVClient: Changing the resource doesn't work there either. I don't get an exception like with JSONClient, but simply nothing happens. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
On Sun, 23 Jun 2019, Sven Barth via fpc-pascal wrote: Okay, independently of whether the REST module is the optimal solution or not, it should work, right? (and shouldn't the Wiki entry then mention the advantages/disadvantages of the two approaches? Cause when looking at the SQLDB REST module I thought "yay, less stuff to configure" and rolled with that) What exactly is less to configure ? :) Looking at the Wiki again I was fooled by the Datamodule having 8 bullet points, the SQLDBRestModule having 5, but the later simply shortening stuff with point five... So yeah... not really less to configure... My fault. ^^' It's OK. I will try to document it a little better. Cause with the changes you committed the example provided with Lazarus still does not work (even if I change MyDispatcher.Active to False and MyDispatcher.BasePath to 'REST'). The error is always "INVALID RESOURCE" which means that ExtractRestResourceName returned an empty string (which is logical, cause there neither exists a route that sets 'resource' nor is HandleMetadataRequest ever called). Ah. Documentation issue. If you use a restmodule, then I expect the resource to be provided using ?resourceParam=Name, not in the URL. See function TSQLDBRestDispatcher.ExtractRestResourceName(IO: TRestIO): UTF8String; Ah! But that isn't mentioned in the Wiki, right? Cause the Wiki only mentioned the URL based stuff and thus I assumed the SQLDBRESTModule to behave the same... Well, ideally it would be so, and I think I have a way to do it without additional options: the module can simply set the routing params before calling HandleRequest. By the way: I sometimes get a EStreamError *after* all data had been sent to the client. I have not yet found a reproducible way for this... Please make sure you have the latest version of everything: I had this a couple of times in case of an error. I fixed all occurrences, I hope. But if you find additional cases: let me know. We can of course change that to try and look in the URL as well using GetNextPathInfo on the request if the routes are not registered, that should work. But then it needs to be done early on in the HandleRequest because the rdoInConnection needs to be observed, so the path can be read only once. It will probably require a new rdoUseRequestPathInfo, which could be set by the restmodule... I will look at this. Would at least be nice to not have to care how one needs to call the server side... I agree, see above :) - localhost:8080/metadata works - localhost:8080/users returns "INVALID RESOURCE" Because it has rdoConnectionInURL set, and so you must do localhost:8080/expenses/users Ahh! Hadn't seen that this option is active... Okay, then it indeed works as expected, both with and without rdoConnectionInURL. By the way: I noticed a slight annoyance, but I don't know whether one can really do something about that: When I set rdoConnectionInURL to False inside the object inspector it turns on again, because rdoConnectionResource is set. Took me a moment to look at the source code to see that I need to disable rdoConnectionResource first. Don't know what a better solution would be... Funny you mention this, I was fooled myself yesterday, I also had to look in the sources :( One way would be to disable rdoConnectionResource if you disable rdoConnectionInURL. I will add this. Further thing I noticed when testing BufClient and CSVClient: Changing the resource doesn't work there either. I don't get an exception like with JSONClient, but simply nothing happens. Strange. I will test the examples again. Thanks for pointing it out ! Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Am 23.06.2019 um 11:31 schrieb Michael Van Canneyt: On Sun, 23 Jun 2019, Sven Barth via fpc-pascal wrote: Okay, independently of whether the REST module is the optimal solution or not, it should work, right? (and shouldn't the Wiki entry then mention the advantages/disadvantages of the two approaches? Cause when looking at the SQLDB REST module I thought "yay, less stuff to configure" and rolled with that) What exactly is less to configure ? :) Looking at the Wiki again I was fooled by the Datamodule having 8 bullet points, the SQLDBRestModule having 5, but the later simply shortening stuff with point five... So yeah... not really less to configure... My fault. ^^' It's OK. I will try to document it a little better. Would probably be best, thank you. :) By the way: I sometimes get a EStreamError *after* all data had been sent to the client. I have not yet found a reproducible way for this... Please make sure you have the latest version of everything: I had this a couple of times in case of an error. I fixed all occurrences, I hope. But if you find additional cases: let me know. Yes, I was using the latest version. But I'll try to find a reproduceable case. :) - localhost:8080/metadata works - localhost:8080/users returns "INVALID RESOURCE" Because it has rdoConnectionInURL set, and so you must do localhost:8080/expenses/users Ahh! Hadn't seen that this option is active... Okay, then it indeed works as expected, both with and without rdoConnectionInURL. By the way: I noticed a slight annoyance, but I don't know whether one can really do something about that: When I set rdoConnectionInURL to False inside the object inspector it turns on again, because rdoConnectionResource is set. Took me a moment to look at the source code to see that I need to disable rdoConnectionResource first. Don't know what a better solution would be... Funny you mention this, I was fooled myself yesterday, I also had to look in the sources :( One way would be to disable rdoConnectionResource if you disable rdoConnectionInURL. I will add this. But wouldn't that lead to an analogous problem with rdoConnectionResource if rdoConnectionInURL is not set? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] why isn't the 'exit' in the finally end clause executed?
On 23/06/2019 09:08, Dennis wrote:
> Using fpc 3.0.4, Lazarus 2.0, the following simple program
>
> program tryfinally;
>
> begin
> try
> Writeln('before finally');
> finally
> Writeln('inside finally. Before Exit');
> exit; // end;
> Writeln('after try finally block');
>
> end.
I seem to remember this was a bug in the Win64 SEH support that was
fixed later on, but I can't find the bug report.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] why isn't the 'exit' in the finally end clause executed?
delphi apparently functions the same if I've read the docs right. something about returning control to the exception handler BEFORE your program gets control back.--Alexander Grotewohlhttp://dcclost.comOn Jun 23, 2019 3:08 AM, Dennis wrote:Using fpc 3.0.4, Lazarus 2.0, the following simple program
program tryfinally;
begin
try
Writeln('before finally');
finally
Writeln('inside finally. Before Exit');
exit; //tryfinally.exe
before finally
inside finally. Before Exit
after try finally block
I have tried putting the try finally block inside a procedure, the same
happened.
program tryfinally;
procedure Test;
begin
try
Writeln('before finally');
finally
Writeln('inside finally. Before Exit');
exit;
end;
Writeln('after try finally block');
end;
begin
Test;
end.
Dennis
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] why isn't the 'exit' in the finally end clause executed?
Am 23.06.2019 um 16:33 schrieb Jonas Maebe:
On 23/06/2019 09:08, Dennis wrote:
Using fpc 3.0.4, Lazarus 2.0, the following simple program
program tryfinally;
begin
try
Writeln('before finally');
finally
Writeln('inside finally. Before Exit');
exit; //
