Hi Russel --
This does raise the question though of what the behaviour of assert is
when it fails. It seems to log a message and the call exit immediately,
it appears to have no notion of an exception. I agree C++, Java,…
exception handling is very complicated and not to be emulated, but for
testing some notion of a failure report out of band of the return value
of a unit is required. Go gets round this by returning a pair, the
value and the error code. Very 1960s, whatever Rob Pike et al. say.
Rust's approach looks superficially similar, but is not, it returns a
wrapper on the return value with the type of the wrapper indicating the
return code. This is akin to the functional programming approach of
using Option.
The upside of Go's approach is that you can write tests very easily.
And they have the advantage of the user/programmer test framework being
the same as the language implementor framework, almost. Mosr
user/programmer people use packages over the top of the base framework
to provide some needed extra features.
Error handling was something we knew Chapel would ultimately need to have
when we started into it, but we considered our plate too full to tackle it
in "v1" and so labeled it a "v2" feature (where those numbers mean nothing
-- it was just our way of stating a good intention at the time).
We've recently ramped up an effort to start defining an error-handling
story for Chapel. You (and others) can peek in on where that currently
stands in the detailed release notes for 1.12:
http://chapel.cray.com/releaseNotes/1.12/08-Ongoing.pdf
Follow the hyperlink in the outline slide to slide 22 or surf there
manually. Note that the complete set of release notes is available here:
http://chapel.cray.com/download.html#releaseNotes
-Brad
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
