1. Error handling again
I'm very happy for all answers received to my previous letter. I've noted
that there are a lot of different points of view on this subject.
I'm not completely agree with the fact that if the language is
deterministic then you don't need of any error-handling:
1. Error handling makes programs more robust (I hope this is the right
adjective) because programmer can handle explicitly all dangerous situation
2. Error handling is the shortest way to correct a complicated function
that fails in a condition leaving a good comprehension of code (even if is
not the best programming architecture)
3. My experience shows me that a deterministic language isn't sufficient to
say that a program has a deterministic behavior: any time you interface
your function with user or physical world you have to test if the status of
all your application is still correct or, more simply, check with error
handling the last interaction.
4. Don't you think why all modern program environments provide a sort of
error handling? Perhaps because every user has his own way of structuring
sw.
From my own point of view the simplest way of providing error handling is
the one uses in VisualBasic.
You declare the way of managing error explicitly with the statement 'on
error' and next describe the action to be done if an error appears. If
there is no error handling in the current function you exit from there and
go to its calling environment and so on until you find an error handling or
you reach the top of your program and the you abort with error.
One of the most useful characteristics of this kind of handling is the
possibility of describing locally or not the managing of errors and that
you have a structure for this. I think this could be interesting.
Thanks for all your answers, they are very interesting.
Just another question: Can euphoria 2 build DLL? I've not try it yet.
2. Re: Error handling again
>1. Error handling makes programs more robust (I hope this is the right
>adjective) because programmer can handle explicitly all dangerous situation
Dangerous situations ??
Well, lets look at it, like it was real life.
With error handling it is like having parents that correct every mistake
you make, so you never have to worry, althrough you might do something you
didn't really want to happen.
Without error handling, your program has to be an adult, think before we
do something.
Programs will not get more robust with error handling, you need to use
types more, with types you can restrict and check values (so they won't
cause an error). And an error that occurs in a different way then when you
call a routine, should always be catched.
>2. Error handling is the shortest way to correct a complicated function
>that fails in a condition leaving a good comprehension of code (even if is
>not the best programming architecture)
Error handling can create such weird situations where you can't
understand an error that has been caused by an error handler. This sounds
complecated, i'll try again:
When a piece of code calls a routine (the only place error trapping
makes any sence) but doesn't generate an error, you make a number of
assumptions. Example:
-- Example code
atom g
g = sort (bla..bla)
? g
-- End
This would generate an error, but what if we used error trapping, well
??
Then we would get the error: g has no value defined, and we'll be lost,
trying to find the answer in either the "? g" or in the decleration.
When you write the error handler you would expect stuff to work the way
you programmed it, but two weeks later, you don't know for what error the
error trapping was ment. (The error trapping would also trap real errors, we
don't want that!!)
>3. My experience shows me that a deterministic language isn't sufficient to
>say that a program has a deterministic behavior: any time you interface
>your function with user or physical world you have to test if the status of
>all your application is still correct or, more simply, check with error
>handling the last interaction.
Again, that's what types is ment for, it is so much cleaner, etc.
Stuff should generate an error, we can use types like this too..
-- example code
type pos_int (integer p)
return p >= 0
end type
integer t
pos_int k
t = -5
k = 4
? pos_int(k)
k = 4.3
? pos_int(k) -- would generate an error, only integers allowed
k = 6
t = k -- would generate an error, cause T is defined
pos_int
-- end of code
And if we don't want the first error, we simply change the type definition
like this:
-- begin
type pos_int (object p)
if not integer(p) then
return 0
else
return p >= 0
end if
end type
-- end
See, how simple, safe, clean & clear ??
Who needs error trapping and why ??
>4. Don't you think why all modern program environments provide a sort of
>error handling? Perhaps because every user has his own way of structuring
>sw.
Error trapping doesn't have anything to do with structure, only with
chaos.
"All modern programming environments" make what sells, not what's best,
and those that are most popular spend more time & money on commercion than
on the quality of their product.
Quality doesn't sell, cause if all people would recognize quality,
everyone would be able to make the best product (or programming language in
this case)
And in languages like Basic, it is needed cause the rest of Basic lacks
any type of structure, functionality and flexibility.
>>From my own point of view the simplest way of providing error handling is
>the one uses in VisualBasic.
>You declare the way of managing error explicitly with the statement 'on
>error' and next describe the action to be done if an error appears. If
>there is no error handling in the current function you exit from there and
>go to its calling environment and so on until you find an error handling or
>you reach the top of your program and the you abort with error.
>One of the most useful characteristics of this kind of handling is the
>possibility of describing locally or not the managing of errors and that
>you have a structure for this. I think this could be interesting.
managing of errors ??
What about complicated programs, where the program includes a library that
just happens to cause an error, because you gave him wrong arguments to some
value (you should have used types!!)
But now, instead of a clear type check error, the same type of error is
somewhere in your code on purpose, now the rest of the code will fail, cause
it responded to an error, that should have been reported (an unexpected
error)
BTW For error mananing in routines, you can work with an global error
flag variable or with an error flag that will be returned. This way the
routine gets to say which type of error should be caught and which not.
Cause even the most sophisticated error trappings mechanisms i've seen
always work with either line number or the type of error generated.
What we want is do catch errors by their cause, however errors ussually
occur in different sections of the code, look at this example:
sequence data
data = {8,"Euphoria"} -- number of chars & chars
-- somewhere in the code ...
data[1] = data[1] + 0.3
-- somewhere else in the code..
puts(1,data[2][1..data[1]-1]) -- prints the chars except for the
last character.
-- end of example
The error will be generated by puts, while the cause it with: data[1] =
data[1] + 0.3
Error trapping will be confusing, and hard to understand (when some1
reads your code)
Types would have worked fine, and would have generated the error at:
data[1] = data[1] +0.3
No, Error trapping is a welfare deceise, something we think we need
cause it sounds so nice, please no...
>Just another question: Can euphoria 2 build DLL? I've not try it yet.
Nop, it is an interpreter in it's hart, maybe someday, but it makes no
real use.
Write DLL's in fast languages, like C or ASM, and call their (fast)
function & procedures through Euphoria 2.0
I don't see the use to include euphoria routines in another language,
cause every1 ever seen Euphoria doesn't need those other language for main
development, that person would use Euphoria for main development and add
fast routines from other languages if needed.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
