Re: Robert Craig... One Wish Please
- Posted by petelomax at blueyonder.co.uk Jul 31, 2002
- 393 views
{{{ On Tue, 30 Jul 2002 23:49:31 -0400, Robert Craig <rds at RapidEuphoria.com> wrote:
at least in principle. It wouldn't be hard to implement,
but it raises some issues that have to be examined carefully,
Agreed. I vote the program *WILL* terminate after the call is made. Basically, (state this) the _on_crash_ routine can be set & is cleared before the routine is called; if the programmer is daft enuf to reset it during the crash procedure *ALL BETS ARE OFF*
- It would be almost useless in code translated to C, since
there are very few run-time error checks. It would increase the
chances that a program could not be translated properly.
I vote: forget this; xlate to C is a speed/release issue anyways. I suspect we're all more concerned with alpha/beta issues.
btw, I'm not up to speed on this. are you saying that given checks such as index of -1 are no longer checked at all in a xlated to c pgm?
- It might make certain optimizations more difficult, since
you couldn't be sure at compile-time that a series of
statements would always be executed in a predictable order.
Erm? I would strongly recommend (if it helps) that such a routine can only exist at top-level; not in an include file; no local vars - & even no calling of other procedures/functions (again if it helps).
be a mistake, since an exception might happen, causing
a sudden jump to a routine that uses that variable, etc.
Erm again, I wouldn't expect either a) more than one fatal error trapping routine, or b) it to have *ANY* access other than to global variables - it's a programming (/er) issue, again. So it would/could only access stuff your standard top-to-bottom interpreter wouldn't dare release yet.
- People might start to "abuse" the feature, using it for normal
processing, not just exceptions, especially when some clever
person reports how he speeded up his loop by 5%, by removing his
test for an out-of-bounds subscript, and relying instead on the
exception handler.
Not at all what I want. I want the program to be able to save some stuff (globals), simple message perhaps, crap out & die as usual. Re-starting the program (eg a long edit) then offers the user a choice of restoring to file-on-disk or applying changes to some workable point (again, up to the programmer to figure that beast out)
- It might preclude doing an eventual full treatment of
exceptions like C and other languages, where > each block of statements can have its own handler.
I wholly, wholly, completely and utterly disagree; this is *NOT* exception handling; this is crap out and die handling. A different beast altogether.
- There are issues, such as: Do we allow the exception handler to return?
- NO*
so it will know what happened? etc.
When possible, but largely, again, this is a programmer issue; It's *much* more important for an app to know which bit it was doing rather than a "divide by zero" just happened, as you all know.
- If you are mainly interested in freeing resources,
you should know that Euphoria flushes your files and closes them,
frees .dll's, and all the memory that you allocated
via allocate() is freed as well.
I trust you wholly in that respect.
<snip>
Rob, you're in alpha mode for 2.4 right now yeah? Live a little Stamp your foot down on some sensible limitations. Please don't use the word "exception"; it only confuses. Try fatal error instead. (or crap out and die handling!-) And yank it if it goes pear shaped.
Pete
