[m-rev.] Improved array error messages

[Ralph Becket]

Fergus Henderson, Monday, 21 January 2002:
> On 16-Jan-2002, Peter Ross <peter.ross at miscrit.be> wrote:
> > I suggest printing out the type of the array which is similar to what is
> > done for map lookup failures.
> 
> I don't think that is a good idea, because it could be bad for performance:
> using the type name could prevent the compiler from optimizing
> away the construction of the type_info in the caller,
> because it would prevent unused argument elimination.
> Performance is important here, because array__set and array__lookup
> are likely to be used in the inner loops of performance-critical
> applications.

Good point.

> Hence the following change.
> 
> ----------
> 
> Estimated hours taken: 0.45
> 
> library/array.m:
> 	- Don't include the array type name in the error message,
> 	  since doing so could inhibit optimization.
> 	- Move the call to throw/1 into the body of out_of_bounds_error/3,
> 	  to improve code locality.
> [...]
> 
> Workspace: /home/earth/fjh/ws-earth4/mercury
> Index: library/array.m
> ===================================================================
> [...]
> +	% Note: we deliberately do not include the array element type name
> +	% in the error message here, for performance reasons:
> +	% using the type name could prevent the compiler from optimizing
> +	% away the construction of the type_info in the caller,
> +	% because it would prevent unused argument elimination.
> +	% Performance is important here, because array__set and array__lookup
> +	% are likely to be used in the inner loops of performance-critical
> +	% applications.
> +out_of_bounds_error(Array, Index, PredName) :-
> +	array__bounds(Array, Min, Max),
> +	throw(array__index_out_of_bounds(
> +		string__format("%s: index %d not in range [%d, %d]",
> +			[s(PredName), i(Index), i(Min), i(Max)]))).

Calling throw/1 means we don't get the software_error/1 wrapper around
the exception.  Do I then take it that software_error/1 indicates an
internal problem (i.e. something the compiler/library writer caused
rather than the user)?

Otherwise that's fine.

- Ralph
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------