I think Ghc does allow catching pure exceptions.
Am 07.06.2011 17:53 schrieb "Yitzchak Gale"
I wrote:
I noticed when looking at the IsString instance for Name: it can introduce crashes into a program if someone accidentally puts a '{' at the beginning of a Name string. Or accidentally omits the '}' in Clark notation. The way xml-types is now, it cannot be used in an environment where code is not allowed to introduce any additional risk of crashes. That is quite common in commercial development.
John Millikin wrote:
The code won't ever *crash*, it will merely throw an exception, which can be caught... Second, GHC's IsString feature is not enabled by default... Third, the IsString instance is largely for convenience...
Sorry, I guess I really wasn't making myself clear.
I never raised any doubts about it being *possible*, or even easy, to write safe code using the xml-types library as it is now.
In a large-scale software development environment, one way that risk is evaluated is by counting the number of ways that it is *possible* for a library to cause a crash. And yes, in this context raising an asynchronous exception that knocks your program all the way out to some last-chance exception handler in the outer IO layer counts as a crash.
Since the whole idea of xml-types is for it to be a unifying standard, I'd like to see it usable in that kind of environment, too.
In addition, I have already pointed out that semantically it doesn't make sense for a fromString implementation to return _|_. And it is easy to make a small change to the current implementation to avoid that.
So let me turn the question around. Is there a compelling reason why, in some use case, the fromString must return _|_, rather than returning some text that will allow the application to handle the situation itself?
Thanks, Yitz
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel