From: Ryan Pavlik <rpav@...>
Date: 2003-03-18T03:13:43+09:00
Subject: Re: Ruby / Eiffel ?

On Tue, 18 Mar 2003 01:26:40 +0900
Friedrich Dominicus <frido@q-software-solutions.com> wrote:

> Ryan Pavlik <rpav@nwlink.com> writes:
<snip>
> > 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.
> 

Exceptions work quite well in these cases.

> 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.

This depends.

If you're just checking if a file exists for some reason, this isn't
an error condition _anyway_.  You're checking if the file exists or
not, and if the file doesn't exist, that is simply the other half of a
boolean.

Now, if the user tells you "open this file" and it fails, that's a
good place for an exception.


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

Why?  In Mephle, I'm using exceptions for just this.  Works great.
See, when you have an exception, it's really easy to make a nice
dialog or other interface component at a higher level to inform the
user what's wrong.

You then don't have to:

    res = func_call()
    if error; ...
    another_call()
    if error; ...
    do_something()
    if error; ...

So, why are exceptions the "wrong approach" again?


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

And that good reason is what?  Maybe Eiffel exceptions are just not
very wieldly, or they're overly slow, or cause code bloat.  (I don't
know that they are, but this is a problem in C++, so who knows.)

Since they're extremely useful as demonstrated above, I haven't heard
mention of a better alternative, and Eiffel doesn't use them, it
sounds like a techincal problem.

<snip>
> > 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. 

This makes no sense.  First, I said "programmatic" knowledge... that
means the _code_ asks "what does this function take".  Does Eiffel not
allow you to construct method calls or use subclasses in place of the
given parent class for a parameter?  The programmer looking at the
signature is irrelevant.  The _code_ should be able to look at the
available functions, and construct calls to them.  Perhaps you
misunderstood what I'm getting at.



-- 
Ryan Pavlik <rpav@users.sf.net>

"Should I be worried, impressed, or *insulted* that you
 could so easily imagine me as a pretty unicorn princess?" - 8BT