On 27/06/2011 15:58, Hans-Peter Diettrich wrote:
Martin schrieb:
See my example about memory alloc in my other mail. It shows, that a
piece of code (and it's ability to be "safely invoked ") does not
solely depend on the parameters passed, but also on (selected parts
of) the state of the application or system.
What when some code does not return anything, *and* cannot work at all
due to some problem (out-of-memory, file deleted, object destroyed...)?
When e.g. a file search cannot proceed due to missing access rights?
It cannot return an boolean value (succ/fail), because it's simply
unknown whether the file exists.
When in case of an unexpected error the called procedure throws an
exception? Can this procedure *ever* be "safely invoked", when it may
return to some other place in code (exception handler)?
Yes, why not. IF this is the defined behaviour. Exceptions can be
caught. To safely call such a function one would need to define an
exception handler. But it can be safely called.
That a function can be safely called does not mean that there is no way
to call it unsafely.
A function expecting a pointer to some specific data, may be able to
check if the pointer is nil, but it can not necessarily check if the
pointer is otherwise valid.
Hence input range for which the function is defined, is a pointer that
is nil, or pointing to the correct type of data. Within this range of
input the function may be called and will be safe, with other input the
result of calling the function is not defined, hence it is not safe.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
