Am Wed, 15 Aug 2012 23:29:43 +0400 schrieb Dmitry Olshansky <dmitry.o...@gmail.com>:
> When I see code like this I have one single thought - error codes! > > Indeed that's what is used in this example, with Exceptions only being > convenient (and separate) transport for error codes. So the net progress > is creating 1:1 type for each error condition (start counting the lines > of code) and then... > > If I got it right somewhere later foo is supposed to be used like this: > try{ > ...some_code > foo(); > ...other code > } > catch(UnexpectedResponseException) > { > print error and disconnect this server or retry? > } > catch(UnauthenticatedException) > { > print error 2 > } > catch(SecurityException) > { > sslFoo(resp); // this one is just awesome ;) > } > catch(DisconnectException ) > { > print error 3 & (ask to) reconnect? > } > > Or used a catch all and do type switch Java-style to see if Exception is > one of interesting to you types. Needless to say awful again. > > First SecurityError is gross fiction as you either know to authenticate > (need credentials in the interface) or do auto detection (like try > HTTPS, then fallback to HTTP). > > Moreover encoding _cause_ of error in type is useless, end user needs a > hint on the proper way to handle error. It's like pointing out a guy who > made the mistake and how stupid it is instead of proposing the ways to > fix the situation. > > what I'd expect the code to be is (been discussed before): > class NetworkException > { > @property bool transient; // packet lost or whatever, can re-try with > the same parameters > @property bool lost; // need reconnect to restore, server down or > disconnected or unexpected input > @property string msg(); > } > > This reduces all the handling to: > catch(NetworkException ne) > { > if(ne.lost) > //ya kill me, but you got the idea ;) > goto ReconnectAndRetry; > if(ne.transient){ > warning("..."); //log failure > goto RetryAndCheckTryCount; > } > error(ne.msg); > } > > Including but not limited to the time when foo's author adds more types > to his "throws list". Unlike checked exceptions it won't break build > just for the fuck of it *and* it will still work correctly. > > In fact if we manage to come up with proper reasonable standard > exceptions like Network/IO/etc. that everybody derives from error > handling would become damn easy with *any* library. Just for the fuck of it, huh :) ? Interesting read, do you know an example, probably a standard library of some other language, that offers standard exceptions like this? If I understand you correctly, the idea is to not use distinct error ids (be they codes or exception classes), but a mix of flags. So you'd have pretty much one "catch" with a few "if"s, but with the flags you can decide on the granularity. -- Marco