Andrei's Google Talk

[Pelle]

On 08/05/2010 05:34 PM, dsimcha wrote:
> == Quote from BCS (none at anon.com)'s article
>> A possibly better solution would be to use an error handling strategy approach,
>> Have the called function throw and exception supplied by the calling function.
>>>
>
> I wouldn't use this, at least without a sane default exception, because it forces
> the caller of a function to write boilerplate for error handling (beyond what's
> necessary for cleanup/rollback in case of an error) even if the caller can't
> actually handle the errors.  This severely smacks of overengineering and making
> the uncommon case possible at the expense of making the common case simple, and
> largely defeats two main purposes for exceptions:
>
> 1.  Noone should have to explicitly think about how to propagate any error.  One
> and only one level should have to think about handling it and the rest of the
> levels just need to be able to clean up in case of an error.
>
> 2.  Exceptions are supposed to provide a sane default that's useful for small
> scripts (exiting the program with a decent error message).  If you force the user
> to explicitly specify an exception to be thrown, you lose this convenience.
>
> On the other hand, if you provide a sane default exception, this might be
> reasonable as long as it doesn't bloat the API too much.

enforce(a<b, "a needs to be smaller than b"); // Exception
enforceEx!(RangeError)(a < length, "a out of bounds"); //RangeError

Isn't this exactly what you want?

Probably, an overload for enforce could be made, so this works:

enforce(a < len, new RangeError("out of bounds"));