On Fri, 14 Mar 2003 13:00:07 +0900
"Jason M Jurkowski ;002;icsg6;" <jmj8237 / cs.rit.edu> wrote:

<snip>
> exactly.  i believe  eiffel makes a big deal about them as part of "design
> by contract"

I believe "design by contract" is flawed, but that's another
discussion entirely.

<snip>
> sometimes assertions don't check adherence to an interface.  sometimes you
> like to add assertions to help you determine where a program went wrong.
> you find which part of your understanding "broke first."

Exceptions do even more for you.  Assertions are nothing more than
convenient print/exit statements.  Exceptions by default do the same,
with the addition of backtrace information (which is usually useful in
determining the erroneous path).  This is nice for debugging.

With a little extra work, you can write your code to "fix itself".  At
very least they provide nice error reporting (to your code, instead of
something like errno), but you have the opportunity to handle and try
and correct the problem on the fly.  This is especially important in a
dynamic system like Ruby, where things, well, change.

> i've coded up a ruby "assertion" for myself as follows:
<snip>
> maybe as i learn more ruby i'll find less of a use for it.
<snip>

I'm really not sure what this gives you other than less information
over the original exception.  Backtraces are a nice way to see how you
got to the condition in the first place.  Your only choice later is to
remove the abortive statement, as well---there's no possibility for
adding checks to handle the situation at a higher level.

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

"Fanged death from the sea is quite routine." - 8BT