>"I didn’t really know how to answer that at first ... Http ... Cert error ... " Here's what I would have preferred to see: - review of dbc, hoare logic. Gett

>"I didn’t really know how to answer that at first ... Http ... Cert error ... " Here's what I would have preferred to see: - review of dbc, hoare logic. Getting lost in atom sized details about how to return errors rolling into language keywords, and exceptions is pointless without first establishing defined v. undefined behavior. How should I deal with sqrt of -1? Exceptions? Error code? Errno? Logging? Some zig key word? First get straight the check for negative numbers is the caller's prob or should be. If caller/callee have decent unit testing w/assertions most of this code can defined out for prod release. Passing a url as a string v. a url object from a cache where it was at least once known as a good url that dns likes is a much about contracts as it is about nitty gritty like error reporting. - some non trivial c++ libs are exception free except where a standard requires it. These libs use a pretty clean error api with heavy contract definition. See Bloomberg's stl replacement BDE open source. Big. Non Trivial. Clear api. And it works. - pigeon dropping code is unsightly and also a good measure of how much can go wrong if one bothers to think about it. If you never thought about the contract lack of pigeon code is ignorance not help. Here go isn't the cancer ppl make it out to be. - a good alternative to pigeon dropping code is error callbacks. Rougewave's cross platform c++ lib from 90s gave me this idea in th context of dbs. Sick of doing a one line sql thing then 10 lines of error checking? The api had a callback with good context to rollback etc. This way the good and bad case code is more consolidated. Erlang supervisors may be like the MT version of this