Greg London wrote:
>>> And no open-ended processes are allowed per frame.
>> But.... Nothing about throwing exceptions is open-ended.
>
> How deep is your stack?
That does not really matter. What matters is the complexity of the flow.
I suspect I know what you're thinking here, based on what you say below; but
it's not the only possible scenario, and it's not what I am trying to advocate
as a reasonable use of exceptions, or even exceptions-as-goto.
For example, consider code with a single exception handler which sits at the
top of the program (first stack frame). Any exception, anywhere will jump to
this code and run it. That's pretty simple. It may pop 3 frames or 300.
Dosen't really matter; The complexity of the flow is, fundamentally, almost no
different than if the "throw" was rewritten to be a "call" to a function that
does whatever the handler does -- the key difference being that the stack
pointer is adjusted so that you can "return" to the top-level in one hop,
instead of having to "return -1" and test that 3 or 300 times, at each level
doing another "return -1" to pop one more stack frame off. That's the "win".
But it does not have to be complex or difficult to analyze. It could be. But
it does not have to be.
>> It "simply" pops the stack & starts to execute some other code.
>
> at least in life critical avionics, the verification
> process is bottom up. You verify the low level blocks
> do what they're supposed to do, and then you integrate
> the blocks. Integration does not change the behaviour
> of teh blocks, so integration does not require that you
> verify that you created new behaviours.
>
> How do you verify a low level block that does a throw?
> It will behave differently depending on who is doing the catch.
You have put the cart before the horse here. Or perhaps the airplane before
the tug.
The verification process you describe is premised on the idea that exceptions
are outlawed; and thus it would be hard to verify code with exceptions using
that process. Ok. Fine. No one is saying you need to use exceptions. No one
is saying that airplanes and life critical avionics need to use exceptions.
Heck, I am generally saying that there is a time & place for everything. And
that time is not "always" and that place is not "everywhere". But, if
exceptions were not outlawed, perhaps a different verification process would be
able to analyze appropriate use of them effectively.
It's not a campaign to change avionics. It's not even a campaign to advocate
using Perl for avionics. If anything, you're making my general (marketing)
point -- Perl isn't best for everything.
> [...]
Not necessarily.
> At which point, the desktop application programmer will say
> something along the lines of "But I know what I'm doing".
>
> And the FAA guy will say "I can't prove that".
But do all programming techniques need to be approved by the FAA?
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
