On 2012-05-30 23:16, Jonathan M Davis wrote:
You can catch them to print out additional information or whatever is useful to generate more information about the Error. In fact, just what the Error gives you is already more useful: message, file, line number, stack trace, etc. That alone makes an Error more useful than a halt instruction.
If I recall correctly you has been arguing that Errors shouldn't be catchable, as they are today, and this needed to be fixed. Hmm, or was that Steven.
You can catch them to attempt explicit cleanup that absolutely must be done for whatever reason (with the knowledge that it's potentially dangerous to do that cleanup due to the Error). You can catch them in very controlled circumstances where you know that continuing is safe (obviously this isn't the sort of thing that you do in @safe code). For instance, in some restricted cases, that could be done with an OutOfMemoryError. But when you do that sort of thing you have to catch the Error _very_ close to the throw point and be sure that there's no cleanup code in between. It only works when you can guarantee yourself that the program state is not being compromised by the Error, and you're able to guarantee that continuing from the catch point is safe. That works in some cases with AssertError in unit test code but becomes problematic as such code becomes more complex.
I'm mostly interested in letting the user know something went wrong and then exit the application.
-- /Jacob Carlborg
