|
From: Donal K. F. <don...@ma...> - 2008-11-20 16:41:10
|
Neil Madden wrote: > I believe this is already addressed by the presence of errorCode. > Pattern-matching against this code is already quite simple, with > [switch] and so on. It just hasn't caught on. It seems like wishful > thinking to expect that it will suddenly catch on just because its usage > is made slightly more convenient (we're talking about a reduction of > about 1 line of code). Also a reduction in the nesting depth. That reduces user-visible complexity. That's a good bonus. > 4. Trapping only those errors/exceptions you are interested in > -------------------------------------------------------------- > > It's clear from the above that the Twylite/JE approach achieves this for > errors, but not for other exceptions. My approach achieves it for > exceptions but not for more specific error cases. The problem with making more use of exception codes is that they're a global resource; they're not easy to restrict to a single interpreter. That makes them significantly less suitable for use in packages, and hence restricts their general applicability rather a lot. They've also got hard-coded traceability behaviour (i.e. none). > Branching based on the result just seems like a fragile nightmare. > Localised error messages for instance could totally change the behaviour > of code. Agreed. And localizing error messages is messy too without in effect the effort required to generate errorcodes properly. Which in turn makes the error trapping proposed viable and useful. :-) Donal. |