![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
"Also, for Rust 2, I'd suggest exceptions. The "new error handling model"[1] is excessively verbose. Repackaging low-level errors for the next level up requires considerable coding. I understand the big problem with exceptions is what to do about unsafe code. I'd suggest "just say no". Unsafe blocks cannot raise exceptions. If an exception in safe code unwinds into an "unsafe" block, it becomes a panic. Unsafe code in Rust is usually to interface with non-Rust code. If you have unsafe sections in pure Rust code, you're probably doing it wrong.
The secret of exception sanity is a standard exception hierarchy, like Python's. Catching an exception class in Python also gets all its subclasses. "EnvironmentError?" covers all I/O errors, network errors, and such, but doesn't cover internal program errors. New user-defined exceptions are added below the most appropriate part of the standard exception hierarchy. So Python usually doesn't have Java's exception hell. If exceptions go into Rust, do it that way. Require that all exception objects descend from some predefined exception object in the standard exception hierarchy.
An additional advantage of a standard exception hierarchy is that it leads to straightforward internationalization. If all the standard exceptions have translations, users get semi-reasonable error messages in their own language. If you have too many string-type error messages in a program, it's hard to handle multiple languages.
Go is starting to get exceptions through the back door. People are abusing the "panic"/"recover" mechanism in Go to get exceptions.[2] Don't go there.
[1] http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ [2] https://code.google.com/p/go-wiki/wiki/PanicAndRecover#Usage...
mercurial 14 days ago
> The secret of exception sanity is a standard exception hierarchy, like Python's. Catching an exception class in Python also gets all its subclasses. "EnvironmentError?" covers all I/O errors, network errors, and such, but doesn't cover internal program errors. New user-defined exceptions are added below the most appropriate part of the standard exception hierarchy. So Python usually doesn't have Java's exception hell.
You know, Java also has a standard exception hierarchy. However, whether in Java or Python, it usually makes sense for the exceptions of a library NOT to be part of the standard hierarchy. For instance, SQLAlchemy's exceptions all inherit from SQLAlchemyError?. It's the same thing in Java.
"
---
i might recommend multiply-inheriting exceptions then.. so eg something can be both an SQLAlchemyError?, and an EnvironmentError?.
---
this sort of thing is a real problem:
" You've got a deeply-nested set of objects that may or may not always be there. We've all seen something like this: var myURL = app.config.environment.buildURL('dev'); which leads to one of our favorite javascript errors... error: undefined is not a function
And the solution only makes the code base ugly:
var myURL; if (app && app.config && app.config.environment && app.config.environment.buildURL) { myURL = app.config.environment.buildURL('dev'); }
We all hate that, don't we? " -- https://github.com/letsgetrandy/brototype
or what if it is
app['soap:Envelope']['soap:Body'][0].getResponse[0]['rval'][0].customerId[0]
?
https://github.com/letsgetrandy/brototype is one soln but with a new language we can do better (by not having to repeat the thing twice)
---
make syntactic sugar to have a more structured version of:
raise Exception('image_mask_onto_atlas_superimpose_pipeline: ABA returned failure; request = %s, parsed response = %s' % (url, data))(Python lets you put other data in the fields of the Exception, this is too much typing; but if some of these were standardized (eg semantic name of the part of program raising the error; error msg; details) it could be made easier to type)
---
would be really nice if stack tracebacks printed not only everything that Python does, but also:
MichaelOChurch? complains that "Java’s type system lacks the power to verify that a String variable, at compile time, will actually hold a string, and not null, a value that must be handled specially by any method that takes a String (ditto, for any other object type) as input. The string type is not available; you must make do with what is, in fact, a (string option) ref— a mutable reference that may hold a String.".
Which suggests that:
---
to tame event-driven programming, propagation hop limit (preferably continuous, but i don't see how that would work)
(my friend G.B.'s idea)
---
(adjustable) limit on # of statements in a transaction, to guarantee termination
(my friend G.B.'s idea)
---
when transactions fail, retry afteer a raondom time interval to prevent the same sequence of events potentially recurring and causing starvation
---
pervasive patterns builtin to the std library and mb the language:
---
