Natalie, Quite frankly, I don't think that there's any valid rationale for defaulting to an error code that is supposed to be originating from the server --- even when following the author's recommended usage.
This happens to be one of several simpler, straightforward problems that I raised a few years ago. I thought that it would be pretty obvious to anyone with relatively little consideration (and not even that much experience) that this was an improper set up. It also seemed that this was one of the EASIEST things to fix (in a library I liked so much, I really wanted to help in several ways). [However, it's related to a much larger and more complicated set of issues regarding error reporting/classification in the Synapse library that most definitely is not so easy to resolve (or even to agree on <g>).] But the author disagreed, and there was no other (posted) support within the mailing list, so it didn't change. [One way to deal with this as well as other feature additions, etc. is to create your own wrapper library... ] The library's author, Lukas, states his case and expected usage in the following mailing list message (that you're supposed to only consider/inspect result codes if and only if you got a valid return (true) from the HttpMethod call): http://www.mail-archive.com/[email protected]/msg01765.h tml Which, however, does not in the slightest mean that it is good to default to an error code that is misleading, instead of choosing one that is obviously not in the currently used HTTP error code range. Even if that's only to prevent misinterpretation by users not knowing that that's not the proper way of doing things. A very valid design criterion in itself. You might be interested in that entire thread, including these messages, in which I plead <G> for a change: http://www.mail-archive.com/[email protected]/msg01761.h tml http://www.mail-archive.com/[email protected]/msg01764.h tml ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
