Re: [fpc-devel] Avoid exception if FPHTTPClient cannot connect to server?

2017-07-31 Thread Michael Van Canneyt



On Mon, 31 Jul 2017, Werner Pamler wrote:

Agreed. This is the same situation as with string-to-number conversion: 
StrToFloat fires an exception if the string is not a valid float, but 
there's also a "TryStrToFloat" which by-passes the exception and just 
returns a false in case of an error. Why not having something like a 
"TryGet" which returns true only if the file is successfully downloaded 
and false in all other cases (HTTP error, or no connection)?


Because that would require to completely change the interface and possibly
implementation of underlying/intermediate methods, which rely now on an 
exception being thrown.


It's of course possibly to make a TryGet which calls get and catches the 
exception,
but you can make such a function yourself, I really don't see the value:
in my experience, you usually want to know why the call failed, and then the 
exception is useful. A boolean value of 'false' is not very descriptive.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Avoid exception if FPHTTPClient cannot connect to server?

2017-07-31 Thread Werner Pamler
Agreed. This is the same situation as with string-to-number conversion: 
StrToFloat fires an exception if the string is not a valid float, but 
there's also a "TryStrToFloat" which by-passes the exception and just 
returns a false in case of an error. Why not having something like a 
"TryGet" which returns true only if the file is successfully downloaded 
and false in all other cases (HTTP error, or no connection)?


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Avoid exception if FPHTTPClient cannot connect to server?

2017-07-31 Thread Michael Van Canneyt



On Mon, 31 Jul 2017, Werner Pamler wrote:

Here is a little demo program which uses fphttpclient to download some 
file from some server.


If the URL exists everything is fine (note on Windows, that the OpenSSL 
dlls must be copied to the exe directory for the demo to work). If the 
URL does not exist, but the server responds, the program returns the 
well-known error 404 (if the 404 has been added to the response codes in 
HTTPMethod) - also fine. But if a connection to the server cannot be 
established -- maybe because the server URL is wrong -- then the program 
creates an exception. Synapse, on the other hand, does not crash on this 
occasion, it just returns an error 500. This behavior appears to be much 
more consistent than fpc's.


Is this intentional? Or should I report a bug?


This is very intentional.

Returning a 500 on connection error is plain wrong. 
Status 500 indicates an internal error on the server. 
This is an 'agreement' governed by a RFC.


But if the connection cannot be made, there was no server, 
and there cannot be a server status either.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Avoid exception if FPHTTPClient cannot connect to server?

2017-07-31 Thread Karoly Balogh (Charlie/SGR)
Hi,

On Mon, 31 Jul 2017, Werner Pamler wrote:

> If the URL exists everything is fine (note on Windows, that the OpenSSL
> dlls must be copied to the exe directory for the demo to work). If the
> URL does not exist, but the server responds, the program returns the
> well-known error 404 (if the 404 has been added to the response codes in
> HTTPMethod) - also fine. But if a connection to the server cannot be
> established -- maybe because the server URL is wrong -- then the program
> creates an exception. Synapse, on the other hand, does not crash on this
> occasion, it just returns an error 500. This behavior appears to be much
> more consistent than fpc's.

I disagree. I think generating any HTTP error code locally, which should
always come from the server is anything but a good idea. It could mask
true server issues from network connectivity issues, which distinction
could be still relevant and the client application might want to employ
different error mitigation techniques to solve one or the other case.

> Is this intentional? Or should I report a bug?

The code in FPHTTPClient has an explicit Raise line when the connection is
unsuccessful. So I'd say this is not a bug, but by design. Maybe this
behavior should be better documented or the Exception itself could be more
descriptive tho', but I haven't tried this.

(Note that I generally dislike APIs which are designed to throw
exceptions, but anyway, in this case it looks like it's by design and it's
still better than just generating a random HTTP code locally.)

Charlie
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel