I understand the issue but for it to be an issue than the error path must be common which is IMHO rare .. eg maths libs rarely need it .. yes if you send a stack of 0 to a div op ( or similar) you can get a lot of div by zero exceptions but you as the consumer of the math lib are violating that errors are rare ( div by zero is a real life error) and you can check that yourself. If ( I ==0 ) before calling the lib as an optimization ...
The only time you throw / catch exception frequently are 1) Using it for control flow. Which is bad anyway 2) validation .. validation type work gets a try parse.. You say we don't know how a library will be used but I think we have seen a lot of code and we can make prediction how rare things will be. If 1 in 100 projects have to work their way around it that's no big deal to me. Also for someone else lib it's likely the exceptions maybe quite deep and the stack unwind / finalization cost of intermediate objects will dominate . So to design the whole lib for any user requires significant constraints eg cheap unwinding ( so exceptions can't be deep , be careful of finalizers) with no inheritance etc which is quite unattractive to me ... I don't know any libs which are designed like this. If users have unusual requirements of the lib that causes errors then the user should correct them not the lib designer. Try parse is an example of a common case hence the lib was changed.. I think this is the key point when you are in c style you carefully make sure the return path is fast because the code that does it is in front of you ..when you work with exceptions you forget it and focus more on lib maintenance , easier to use interface etc.. Ben From: [email protected] [mailto:[email protected]] On Behalf Of David Jeske Sent: Friday, 16 August 2013 11:28 AM To: Discussions about the BitC language Subject: Re: [bitc-dev] type-safe modularity challenges for exceptions and error-return On Aug 15, 2013 7:04 PM, "Bennie Kloosteman" <[email protected] <mailto:[email protected]> > wrote: > Im still not convinced its worth it compared to a few cases of tryparse() I don't think I've been clear enough. Tryparse is not the problem. The problem is you can't add try* versions to someone else's library! I don't see the point of slow exceptions thrown from libraries, since they have NO IDEA how they will be used, or what failure frequency will be. I reject the idea that a library author can judge frequency of any failures other TT Han those during one-time init - and even then it is dicy.
<<attachment: winmail.dat>>
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
