Exceptions, was newbie questions

[Lars Hupfeldt Nielsen]

Hi,

I compleetely agree that exception usage in the library is not 
consistent. In general all errors should be exceptions. There might be  
a few exceptions to this rule, but there is absolutely no reason that 
the FILE classes should not raise exceptions. And yes, exceptions 
should be differentiated by class.

Lars

I also agree that a mode option might be better on the FILE::open 
procedures.


>The FILE class has open_for_this, open_for_that, etc. which are just 
wrappers
>around various fopen modes.  I'm curious as to why it doesn't simply 
provide a
>open(fname:STR, mode:STR):SAME or create method.  I see the mode 
string in
>fopen as being a "little language", like printf format strings, that 
becomes a
>large set of unwieldy methods when moved to another language.
>
>mode string pros:
>compact
>easy to read
>easy to write
>
>cons:
>must be learned for "easy to read" and "easy to write" to be true
>
>sather method wrapper pros:
>easy to read without learning them
>
>cons:
>wordy
>hard to write
>hard to learn (is it open_for_reading?  or open_for_write_truncating?  
do we
>               really need BFILE which is almost exact copy of FILE?)
>
>In the case of a mode string, the "must be learned" con isn't even a 
con if
>the user knows the posix interface (which many languages, including C, 
use).
>
>Since it would have been actually easier to provide a single 
FILE::open
>method, the reason it wasn't must be cultural.  The sather tutorial 
and faq
>make no mention of what 'sather culture' is I have to ask here :) 
Perhaps it's
>like 'smalltalk culture' which has a reputation for a NIH streak :)  
Do we
>really need FILE::current_loc when 'tell' is shorter, perfectly 
reasonable,
>and already standard?  Who on earth wants to type 'create_directory' 
when
>'mkdir' is already standard?  And what's with this 'size' vs. 'length'
>schizophrenia?
>
>I also have a disagreement with #FMT... it makes up it's own 
formatting
>language, which doesn't appear to have any advantage of printf-style, 
but
>fortunately, it also supports printf-style.  Unfortunately, it loses *
all*
>points by trying to *guess* between the two.  Aaaarrrggghhh!!  And 
provides
>no way to say "no really, I *do* know what kind of formatting I'm 
using,
>please believe me".  Simple text formatting like this is so essential 
to so
>many kinds of programs we really shouldn't have a brain-dead design 
here (no
>offense to the guy who wrote it! :).  python overloads '%' to format a 
string,
>and while I generally disapprove of overloading unrelated operators 
for random
>things, it turns out to be incredibly handy.  It's an idea that's 
begging to
>be stolen (ruby already has) :)
>
>That said, mini-languages, while frequently quite nice, are often a 
trap of
>their own.  I believe the continual upgrading of regexp capabilities 
in perl
>is such a trap.  If they aren't already, perl regexps will soon be 
turing
>complete and people will write web servers in them.  I'd prefer a 
standard set
>of backtracking parsing combinators (but that, also, is a sort of
>mini-language).  sather appears to have no call/cc (except implicitly 
in
>iters), but it looks like laziness and thus backtracking could be 
implemented
>using bound methods and an iterator.
>
>
>
>Another question is exception usage.  Again, from the FILE class, it 
seems
>sather convention is to not use exceptions, but provide error methods.  
This
>means that every single file open must be explicitly checked for 
error, or
>else you get a segfault.  This is not much better than C!  One of the 
nice
>things about python is you don't have to deal with stuff like that, 
thanks to
>exceptions.  The tutorial mentions that this convention is because 
exceptions
>are inefficient in sather.  If this is the only reason, *how* 
inefficient are
>they?  Do you pay the penalty only if the exception is actually 
thrown, or do
>you pay for the mere possibility that an exception *might* be thrown?  
And is
>it really worth sacrificing the safety and error reporting exceptions 
provide
>for a little efficiency?  And in the case of FILE, does it really even 
give
>you any efficiency benefit?  If you have performance-critical code 
that
>depends on being able to open files as quickly as possible, I'd really 
like to
>know what you're writing :)
>
>This corresponds with a seeming general lack of use of exceptions in 
sather.
>For example, I can find no standard exception classes, generally STRs 
or INTs
>are used.  This means you catch by STR or INT instead of by type of 
error,
>which hardly seems desirable.
>
>Once again, this seems to be a cultural thing, since there is nothing 
about
>sather (except efficiency, perhaps) that prevents there being a 
standard
>exception hierarchy that is used by the standard library.  Even 
python, with
>its lack of emphasis on performance, provides 'raising' and 'non-
raising'
>versions of certain methods that tend to need to be fast (e.g.
>"string".index(s) throws an exception when s is not in "string", while
>"string".find(s) returns -1).  Of course, in python, you don't pay for
>exceptions if they don't get thrown.
>
>If exception use is generally deprecated in sather, why not take it 
out?
>If it isn't, why not use it?  And if efficiency is the main problem, 
shouldn't
>the compiler be fixed to make them more efficient (easy for me to 
say)?
>
>
>One last thing: is there any convention about 'self modifying' methods 
versus
>'create new object' methods?  '!' is already taken, but a *consistent*
>convention would be nice (it's these sort of things that make or break
>stdlibs, I think... and a quality stdlib is *so* important).  sather 
can
>overload based on whether there's a return value...  perhaps this 
should be
>used?  It seems like a simple naming scheme would be a better 
approach, to me.
>
>    append(a:T):SAME is
>        -- A new array conisting of self followed by `a'...
>        ...
>    end;
>    append_d(a:T) is
>        -- Append `a' to self...
>        eee
>    end;
>
>_______________________________________________
>Info-sather mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/info-sather