Re: Ruby / Eiffel ?

Ryan Pavlik <[e-mail]> writes:

> 
> > Using Exceptions for all kine of errors which can happen definitly
> > flawed.
> <snip>
> 
> Now here I disagree.  
Well if we would agree there would be not discussion. 

> Using exceptions for errors allows you to
> consolidate checking and handling code, which alone is worth the
> effort.  Checking for an error condition after every call is
> impractical, and thus error conditions are glossed over, leading to
> bugs.  Exceptions allow all conditions to get through and be handled
> if necessary.
Well I think the following usage of Exceptions is flawed
a) checking user input
b) checking for erros you know can happen on a regular base.

Just a poor example. Checking if a file exists. This is not a place
for Exceptions but for testing of existance and take appropriate
action than. So no Pseudo Code
try open_file
except ... do what it takes while file is not there but

if file.exists? (file_name) ...
else
do something about it.

Another place where Exceptions are the wrong approach checking the
input from a user for "allowed" elements. 

You my check the libraries from Eiffel and there you won't find much
exceptions handling, they do that for good reason IMHO.


> 
> Using them for pre/postcondition checking just follows... if you fail,
> say, a precondition, raising an exception with that specific
> information is more useful than a simple abort.
That is what Eiffel, does and this is what I meant Predonditon check
should be always on, so the use of the feature does know what to
provide. If he fails on it than he/she is blamed not the library
provider. 

> 
> I advocate complete programmatic knowledge of the program itself.
> That is, if it exists, you should be able to query it.  If a function
> takes a type of parameter (or extending this to DBC, has a certain
> precondition), you should be able to ask what it takes.
Well this is necessary in Ruby, but not in Eiffel. You can see from
the signature what type is expected. 


Regards
Friedrich