Possible "throws" syntax

[Marco Leise]

Am Wed, 15 Aug 2012 23:29:43 +0400
schrieb Dmitry Olshansky <dmitry.olsh at 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