[e-lang] Remaining semantic issues

Dean Tribble tribble at e-dean.com
Wed Jun 1 02:34:15 EDT 2005


This is a great discussion.  I want to simply toss in the reminder of 
the keeper pattern for many kinds of errors.  When accessing files, for 
example, I would rather supply a single function (typically an escaper) 
when I get/open the file object.  Then all errors on read, etc. would go 
to that object, which can decide to eject.  This gets rid of all 
individual ejector arguments on requests, provides arbitrarily 
fine-grained error handling, and eliminates the encapsulation violation 
of thrown exceptions in many cases.

> I think this is a terribly important question. My general experience 
> is that API designers go to a lot of trouble to distinguish different 
> error cases, so callers could dispatch on them, but that callers 
> invariably do something like

I see that a lot as well.  This was endemic in Java for a while.

> Perhaps we should adopt a style of accepting optEjectors as named 
> arguments that default to null? 

NOOOOOOOOoooooooooooo!

Making a fundamental facility of the language that will be omnipresent 
in low-level code dependent on multiple, barely tested "features" and 
syntactic "sugars" does not seem like a good idea.

Keepers are good.  Keepers are just objects.  Objects are good.  We 
don't need no stinkin' magic.....

>> I think that there are cases where exception typing is even more the 
>> obviously right solution, that only come up in complex situations - 
>> and most of the E code written so far is trivial WRT necessary error 
>> handling. ...
>
> This sounds plausible, but I'm skeptical. Again, I'd like to see some 
> illustrative examples where code would actually use such type 
> information to do something useful.

I could easily imagine retriable errors (resource busy), recoverable 
errors (optimistic transaction aborted), resource errors (need more 
dough), and permanent errors (no such table).  There's some overlap in 
those categories, but they are all at least plausible for a DB connection.

>>> Not if failures which should be handled are instead done with 
>>> ejectors or ejectoids rather than normal exceptions.
>>
>> Again, I think that these features are critical in some cases, and we 
>> shouldn't throw them out just because we can do the trivial cases in 
>> other ways.
>
I agree in general.  The lack of motivating examples in the E code base 
should not be considered evidence for discarding common practice 
approaches or drawing other significant conclusions.  The original 
inheritance mechanism was problematic because of exactly that kind of 
issue (it relied on conclusions based on essentially trivial examples in E).

For exceptions in particular, there's a fair bit of discussion around 
the lack of interesting distinctions to make based on exception types.  
It would be

>> I have at least one use case for data fields in exceptions in the 
>> E-on-CL libraries:
>>
>> Map#diverge/2 is implemented in terms of FlexMap#putAll/3. In the 
>> event that there are duplicate keys after the key guard has coerced 
>> the keys, it would be useful for the exception message to state what 
>> key is the duplicate. However, this is not yet possible, as the 
>> exception provided by putAll gives only a string description talking 
>> about keys "already" in the map.
>
> This is an interesting case, but isn't the kind of case I'm looking 
> for. The reason is that the use made of the extra exceptional 
> information is merely to enable a more informative diagnostic to be 
> logged, to eventually be shown to a human to aid in diagnosing a bug. 
> As far as the logic of the program itself is concerned, we're still 
> only dealing with a something-bad-happened.

In the E jave implementation, the following 50 or so exceptions get caught:

ANTLRException
AlreadyDefinedException
ArityMismatchException
ArrayIndexOutOfBoundsException
ArrayStoreException
BindException
CertPathValidatorException
CharStreamException
CharStreamIOException
ClassCastException
ClassNotFoundException
CloneNotSupportedException
EOFException
Exception
FileNotFoundException
GeneralSecurityException
IOException
IllegalAccessException
IllegalArgumentException
IndexOutOfBoundsException
InstantiationException
InterruptedException
InvalidAlgorithmParameterException
InvalidKeyException
InvalidKeySpecException
InvocationTargetException
KeyManagementException
MalformedPatternException
MalformedURLException
MismatchedCharException
MismatchedTokenException
NeedMoreException
NoRouteToHostException
NoSuchAlgorithmException
NoSuchFieldException
NoSuchMethodException
NotSettledException
NullPointerException
NumberFormatException
ParseException
RecognitionException
RuntimeException
ScannerException
SecurityException
SignatureException
SocketException
SyntaxException
TokenStreamException
TokenStreamRetryException
UnavailableException
UnknownHostException
UnsupportedEncodingException
UnsupportedLookAndFeelException
java.io.InterruptedIOException
java.io.UnsupportedEncodingException
java.net.SocketTimeoutException
java.security.NoSuchAlgorithmException
javax.net.ssl.SSLPeerUnverifiedException

It is of course hard to determine whether they are caught because Java 
types require it or because someone actually cares.....

>>>> [...] An object could accept either an ejector *or* a function that 
>>>> returns a value [...]
>>>
>>> collection.fetch/2 already uses this pattern, but the argument is 
>>> described as a thunk rather than an ejector. [...]
>>
>> Yes, this is clearly going beyond ejectors. But I think we should 
>> think about the fact that these patterns are possible, and perhaps 
>> work out a common concept/'supertype' of maybe-exiting callbacks.
>
> I think it's a pattern worth documenting and encouraging. Perhaps a 
> naming convention would help make it clear when this pattern is being 
> used.

This should be dominated by the block syntax.  For example:

collection.get(key) else { defaultValue }

demonstrates that we need to think about that syntax's impact on message 
patterns.

> However, if this affects E itself at all, it's a higher-level library 
> issue, and definitely not a kernel language issue, so we don't need to 
> think about it right now. 

Ok.


More information about the e-lang mailing list