OpenEuphoria

2. Re: Try/Catch

• Posted by petelomax Jan 01, 2015
• 6496 views

Raymond Chen is always worth a read:
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx
(whatever gets implemented should address those concerns, and when that bloke says that something is hard, you really should pay attention)

I would think that you need some kind of stack unwind.

All excellent arguments for not adding finally (an awful, stupid, confusing concept) to Euphoria.

If the main point of exception handling is to separate error handling code from the main logic, what is wrong with putting such things in a separate routine?

procedure cleanup() 
    <such code> 
end procedure 
 
try 
   ... 
   cleanup() 
catch 
   ... 
   cleanup() 
   throw(...) 
end try 

or am I missing something?

It makes me madder than hell to think of such a horrible backward construct being added to Eu, if two simple calls would do.

Of course if you are not re-throwing an exception, which I would have thought is more likely anyway, or are prepared to use a simple flag/return value, <such code> can and should just go after the end try.

I randomly stumbled over a possibly interesting snippet from Michael Anderson:
http://stackoverflow.com/questions/10586003/try-catch-statements-in-c
(last post but one) though (as I said) a stack unwind based approach might be better/easier.

Of course the other burning question is why someone might want exception handling:

• to write good quality robust code, but without the messiness of error code handling
• to use badly written unstable garbage, and get away with it.

Personally, I genuinely prefer the messiness of error code handling, as it is easier to follow and easier to debug, and of course I worry that (most) people will think they are getting something which is actually really hard to do right, for free.

Pete

4. Re: Try/Catch

• Posted by andi49 Jan 01, 2015
• 6447 views

Hallo

I'am not sure if i understand the discussion...

But having something like this (like in Pascal) would be more than 'really nice'...

http://www.freepascal.org/docs-html/ref/refch17.html

I think this code is really readable and matches Euphoria's Coding Style.

For sure the language needs to be expanded and we need to know the kind of the exception, maybe Euphoria can't reach this level...

But from my point of view, any errorhandling (no matter how simple) is better than just chrashing.

Andreas

6. Re: Try/Catch

• Posted by dcuny Jan 01, 2015
• 6411 views

This is essentially the same as try/catch.

- David

8. Re: Try/Catch

• Posted by jaygade Jan 01, 2015
• 6397 views

Euphoria has recoverable errors, you just have to check for them. "Get()" and "value()" are the best examples of that. Checking if a file exists is another.

Unrecoverable errors are ones where your program is wrong and is in an undefined state, so crashing is the correct behavior.

Edit: The nice thing about "defer" in Go code is that it puts the release of the resource close to the allocation of the resource, instead of at the bottom of a section of code.

10. Re: Try/Catch

• Posted by petelomax Jan 01, 2015
• 6413 views

Well, most things can run out of memory and all variables can be unassigned, so that's at least 80% of all opcodes. That strategy will make programs nearly twice as big and half as fast.
Anyway, when you get what I mean by stack unwind, I am sure you will agree it is quite essential.

You have to unwind the stack to the context where the exception handling code can execute:

function fdiv(atom a, atom b) 
    return a/b 
end function 
function g(atom c, atom d) 
    return fdiv(c,d) 
end function 
function h(atom e, atom f) 
    return fdiv(e,f) 
end function 
procedure p() 
    try 
        ? g(i,j) 
    catch 
        puts(1,"error in g(i,j)") 
    end try 
end procedure 
procedure q() 
    try 
        ? h(k,l) 
    catch 
        puts(1,"error in h(k,l)") 
    end try 
end procedure 

When you execute/resume at the exception handling code (puts) in p()/q(), the context/call stack must be unwound to that of p/q, not left as it was in fdiv. There may well be a saved context that the exception handler can examine, but the actively running context/stack frame as the exception handling code executes cannot be one from a completely different routine. In Eu, I doubt there is any way round the fact that by the time the puts is executed, a,b,c,d,e, and f may all have been deallocated.

I do not like anything which looks like it is doing something else. If I see return x, or throw(blah), then I expect it to do just that, not nip down and execute some other block of code first, or worse, have a return 1 quietly overridden by a return 2 in the finally block.

I don't understand. Is proper, obvious, clear and straightforward code not going to be executed?
What "guarantee" are you offering that is not already there?
Are you intending to have filtering such that handlers only deal with certain exceptions and implicitly re-throw any not explicitly dealt with?

cleanup(handle), or as below

cleanup(data_structure_the_user_was_working_on), or as below

I have no idea what that means. You handle exceptions in the exception handling code, after the call stack has been appropriately unwound to the correct/calling level.
In the above example, the puts() occurs in p() or q(), and not in fdiv() where the error actually happened.

cleanup(context), or as below

If you are prepared to use the odd control flag and/or result variable, you can write all your cleanup code locally, and you don't need a cleanup() with umpteen parameters.

try/catch is exception handling. Euphoria has always had perfectly good error code handling, by which I mean open() returns -1, get() returns GET_FAIL, or that you can test for divide by zero first.

Hopefully some parts of what I am saying are helpful, and not too antagonistic.

Pete

12. Re: Try/Catch

• Posted by dcuny Jan 01, 2015
• 6366 views

Hi, Pete.

I appreciate your detailed explanation. I think we're talking about different things, so let me focus on those before muddying the waters:

This is not error handling. open() has a defined behavior of returning a value.

By "error", I mean exactly that: a runtime error, where RTFatal is called, and intentional shutdown of Euphoria is executed.

Consider the following code:

s1[i][j] = s2[j][k] 

If i, j or k is out of range, this is a runtime error in Euphoria.

In a similar vein, the following is not error handling, either:

if i <= length(s1) and j <= length(s1[i]) and j <= length(s2) and k <= length(s2[k]) then 
    s1[i][j] = s2[j][k] 
else 
    -- do something else 
end if 

An "error" happens when code executes and triggers an exception/error.

By "error handling", I mean "take action to recover from a exception, and continue normal execution", not "perform some save routine, and then shut down."

See the use case in my prior post for an explanation why I don't consider shutting down to be a preferred action.

I'm not sure what cleanup is defined as doing. Is this something you're proposing, or is already in Euphoria?

- David

PS: I just use italics for emphasis, not irritation.

14. Re: Try/Catch

• Posted by dcuny Jan 02, 2015
• 6398 views

Excellent!

Actually, try/catch gives you more control, because you can see what the error is, and decide what you want the program to do.

If the try/catch/finally is too complex, another option is to go a more limited route, adding these into the function block:

function foo() 
    -- normal function 
catch sequence error 
    -- catch block 
finally 
    -- finally block 
end function 

It's less flexible than full try/catch/finally blocks. For example, you wouldn't be able to nest try/catch/finally blocks in your code. But it would be a lot simpler to code, and give most of the benefits.

Lua actually provides an even simpler mechanism: pcall() is used to wrap any call that might have an error. But that won't work in Euphoria, because it sees an "=" in an argument list as an equality test, not as an assignment:

-- the parameter to foo() is a comparison in Euphoria 
foo( a = sin(x) ) 

-- the parameter to foo() is an assignment in C 
foo( a = sin(x) ) 

- David

16. Re: Try/Catch

• Posted by DerekParnell (admin) Jan 03, 2015
• 6314 views

In order to further the conversation, here is a paper that has some interesting things to say about exception handling.

18. Re: Try/Catch

• Posted by petelomax Jan 03, 2015
• 6220 views
• Last edited Jan 04, 2015

Blimey, I knew things could get messy, but that's just insane. Not compensation stacks per se, but the mess they were intended to deal with. If 1,300 bugs in 27 applications (and the rest, given the lengths the authors go to stress false negatives and unchecked exceptions) tells me anything, it is that we are not looking at something we should want to replicate, whether or not someone has designed a clever mop. Even less when the inventors of said mop concede it could go horribly wrong and isn't really any better than disciplined if-close or much simpler logging.

My choice quotes:

Some suggested simplifications:

• Any try/catch construct in Eu traps ALL exception types.
  (Said constructs can of course be nested to any depth, eg my_application/database/raw_io.)
• Any and all resignalling, if desired, must be explicitly coded.
• Lastly (I bet you can guess this one) ditch "finally".
  (There is already a perfectly viable alternative in the form of delete_routine().)

Also, I came up with an analogy that might be appropriate, which expresses some of my documentation-level concerns:
Exception handling is a bit like a skiing accident - you get air lifted to hospital, patched up, given time to heal, and eventually shown the door. These things happen as fast as they can, but to be honest it is not a particularly clever way to get a free cup of tea. You've probably only got one ski boot, half a ski, and your salopettes have been incinerated. If you want to try going skiing again, then that's up to you. What never ever happens is that you get an air lift back to the middle of the ski slope to continue your skiing run from where you left off. But at least you're not dead, which you would inevitably be without the help of the medics, and the same for exception handling.

Pete

20. Re: Try/Catch

• Posted by dcuny Jan 04, 2015
• 6184 views

I think we need to be clear that there are three different things here:

• Error codes return from functions;
• Ensuring resources are properly cleaned up; and
• Handling exceptions

While they are related, they aren't the same thing.

Exception handling isn't the same as a routine returning an error code. That's a good thing, and I won't argue against it. But it's a different sort of discussion.

The issue of releasing resources is what finally is all about. The cited paper seems to be suggesting something along the lines of how Go handles resources, by pushing deferred cleanup onto a stack.

Conceptually, finally could be implemented in Euphoria without try/catch, by extending the function/procedure block to include the clause:

function foo() 
   object resource = -1 
 
   -- grab the resource 
   resource = request_resource() 
 
   -- do more stuff 
 
finally 
   if resource != -1 then 
      -- release resource 
   end if 
 
end function 

It feels a bit sloppy to put the cleanup in the finally block, but it does allow you multiple exits with the guarantee that the cleanup code gets called.

It's certainly possible to do something more clever - such as what Go does - while staying in the bounds of how Euphoria executes. Certainly, there are some interesting alternatives.

Things get a bit complex when it starts interacting with try/catch, but it's not an impossible situation to code for.

Hopefully this sort of things gets handled when the dtor of the object gets called, so it's a bit of an exception.

Except, of course, that Euphoria doesn't have proper dtors, which makes it interesting to try to wrap libraries like wxWidgets.

It's been suggested that a QBasic approach could be used. The advantage of try/catch is that the code jumps to the catch block as soon as an error is raised. This means that you don't have to litter your code with exceptions.

This isn't going to replace checking return codes from functions like open(). After all, these aren't exceptions.

- David

22. Re: Try/Catch

• Posted by Shian_Lee Jan 04, 2015
• 6146 views

I feel the same.

If possible, current procedures, such as puts(), may or may-not return error status; this will not break existing code. for example:

puts(fn, "...") -- can be used for demos, simple programs, anything...
ok = puts(fn, "...") -- can be used for more critical data.

About exception handling: before adding such a huge headache to Euphoria, it's better to consider carefully the need for it, and the way that most programmers will use it eventually.

Personally, I'm not sure that I can think about a good example for using an error handler. And cleaning up code can be done in many ways, depends on the situation.

24. Re: Try/Catch

• Posted by dcuny Jan 04, 2015
• 6141 views

Cool! I'll look into it, thanks.

- David

26. Re: Try/Catch

• Posted by petelomax Jan 04, 2015
• 6142 views

Behave. I have also expressed precisely that concern earlier in this thread.

Unless we are very clear about this, it is not could or should, but will.

I know you want a fix yesterday, but this is a very real concern and if we do not address it head-on now, then when?

If we just play copy-cat with these "better" languages, what makes you think we won't see 1,300++ bugs per 27 apps?

Don't panic. I am not saying "do nothing", but "get it right".

Pete

28. Re: Try/Catch

• Posted by dcuny Jan 04, 2015
• 6093 views

Yes, and it was quite eloquently stated, too:

I've already clarified that exception handling is not the same as error code handling.

As for what I'd written, what I meant to have written was:

I hope this is more clear. There was no intent to ignore what you'd written earlier.

But did you pay attention to what you're written?

Frankly, it was inflammatory and insulting.

- David

30. Re: Try/Catch

• Posted by mattlewis (admin) Jan 04, 2015
• 6113 views

I wouldn't advocate doing that, either. The stuff gets cleaned up automatically whenever it goes away.

Definitely. Nevertheless, it's important, I think, to point out that capability, which is a bit outside of the normal IL code paradigm. It's really part of euphoria's garbage collection system, which uses refcounting.

Matt

32. Re: Try/Catch

• Posted by petelomax Jan 06, 2015
• 6006 views

Woke up this morning with a head full of this stuff, in particular the "propagate" idea below, so here goes nuttin:

Draft Technical Spec

Some knowledge of the existing compiler internals is assumed. I have tried to keep this Phix/OpenEuphoria agnostic, and quite deliberately as simple as possible.

A new construct is to be added to the language:

try 
   <block> 
catch <e_name> 
   <block> 
end try 

In addition there will also be a new builtin, throw(atom code).

The call stack frame has a new machine-word-sized field, ehndlr. At startup, in the top-level frame ehndlr is set to 0 (likewise for new threads). Call statements propagate ehndlr as follows:

    ==0 -->  0 
    !=0 --> -1 

The try statement saves the old value then sets it to the machine address of the catch statement. Hopefully a bog-standard local unnamed temporary integer variable can be used for this purpose. That original value must be restored immediately on entry to the catch statement, and on any exit from the try block, including exit/break/continue etc. It is worth noting that a return statement pops the call stack and effectively discards the current ehndlr, thus avoiding the 'exit' issue, even for several nested try statements in the same routine. Obviously a throw statement within a try block should be caught by the immediately following catch statement and needs no ehndlr updates whatsoever. Otherwise, the restoration of ehndlr during normal execution stands out as the most fiddly task, in terms of updates to the compiler, and probably requires a new control flag(/var_id) that is saved/restored at many points during parsing. An exit that jumps out of more than one nested try statement may pose additional challenges, but nothing worse than the exit statement itself already does.

The catch statement traps any exception within the try block or any routines it invokes that is not first caught by another nested try/catch statement. Any exceptions that must be re-thrown must be done so manually. As shown next, on entry the value for <e_name> will be in e/rax.

The existing final exception handler needs something like the following new code added to it:

if ehndlr!=0 then 
    <create content for e_name, ref left in e/rax> 
  ::unwind 
    if ehndlr==-1 then 
        retaddr := unwind 
        return (ie standard dealloc, frame discard, etc) 
    end if 
    mov e_e/rax,e/rax 
    mov e_e/rip,ehndlr 
    mov e/rax,EXCEPTION_CONTINUE_EXECUTION  -- (at catch statement) 
    ret 
end if 
<existing code to generate ex.err> 

Sorry, but I have no idea what the equivalent C/Linux code would be like. Obviously, the ability to resume execution depends on the severity of the fault. For example, if the stack is toast, so is your app.

The exception variable is automatically declared (as a sequence) and is most likely to be just 'e' in actual code. Unlike "for i", there is no reason to have e available after the catch, as should no exception occur it would be unassigned anyway.

At a bare minimum, the sequence e contains an exception code and address, but could also hold a routine number/name, and source code line number. The content may differ between interpreted and compiled applications, and the catch code block should be written to cope accordingly.

The throw routine can be trivially implemented as a fatal error, the only technical difficulty would be getting the code parameter into e instead of #80000003 or whatever.

A new error code is required should throw() be invoked when there is no active handler in the current call stack.

34. Re: Try/Catch

• Posted by Shian_Lee Jan 06, 2015
• 6029 views

petelomax,

Please explain me briefly, using simple words, why exception handling became norm in computer programming.

You see, logically it seems to be such a backward technique for programming. Many "exceptions", such as "Drive-not-Ready" are just a Boolean variable that indicates the status of specific hardware; Why then, and how come, this simple Boolean variable turned into a "football game", with Throw, Catch, etc?

If the operating system treats "exceptions" as a simple Boolean flag - why my program must treat it as a football game with many players?

I'm asking you this question because you must know much better then me. It might be a stupid question from others point of view, but I really want a logical and short answer, with practical example(s) - if you don't mind.

I could not imagine an "exception" in industrial PLC programming. A digital sensor can tell only TRUE or FALSE - your program does what ever it wants with this info. An analog sensor can only supply a value within a known range, and again, your program will take it or leave it.
In PLC, "exception" can mean only one thing: The whole factory is on fire, and it's time to call the fire department; i.e. it's not something that the PLC has to deal with.

Why then "some sensors", i.e. some routines, must trigger "exception" in computer programming(?!?) what is the logical reason for this?

Thank you in advance.

36. Re: Try/Catch

• Posted by petelomax Jan 06, 2015
• 5940 views

Maybe for version 2. Can we not just get an int (full 32-bit) working first?

OK, the same document with all the hidden back-end magic ripped out:

Draft Technical Spec

A new construct is to be added to the language:

try 
   <block> 
catch e 
   <block> 
end try 

In addition there will also be a new builtin, throw(atom code).

The catch statement traps any exception within the try block or any routines it invokes that is not first caught by another nested try/catch statement. Any exceptions that must be re-thrown must be done so manually.
Edit: Unlike other languages there is only one (non-optional) catch clause.

The exception variable, e in the above, though it can take any valid name that does not already exist in the immediately surrounding scope, is automatically declared as a sequence.

The sequence e always contains at least an exception code and address, but could also hold a routine number/name, and source code line number. The content beyond the first two elements may differ between interpreted and compiled applications, and the catch code block should be written to cope accordingly.

Obviously the application will terminate immediately (just like 9/0) should throw() be invoked when there is no active handler (try/catch construct) in the current call stack.

38. Re: Try/Catch

• Posted by petelomax Jan 06, 2015
• 5930 views

True/thanks, and ... SLAPS FOREHEAD... there is another I have used quite a bit, by which I mean a lot:

x = s[i] 

(as one of many many similar examples) can be implemented as either:

if not assigned(i) then error(...) end if 
if not assigned(s) then error(...) end if 
x = s[i] 

or

x = s[i] 

and when an exception occurs, figure out the cause -- the latter is, for obvious reasons, significantly faster, in all the non-fatal-error cases!
(in truth, in practice, at the low-level asm level, due to occasional dependencies and/or AGI stalls, it is not always the case, so I often tried both and chose the faster.)

It is perhaps telling that I've done that all over the shop in the back end, because I had to for performance, but never once though it would be a good idea in hll...

Oh yes, I am expecting some juicy comments on that one.

It is quite simply because I prize so highly that very same fast fail mentality that dcuny and others despise.

Pete

40. Re: Try/Catch

• Posted by Shian_Lee Jan 07, 2015
• 5959 views

Thank you.

These answers are really ambiguous for me. Honestly, I don't feel that I got an answer at all.

Once I've programmed a PLC with maybe hundreds of INPUTs and OUTPUTs. That PLC controlled many engines, sensors, and machines with huge power, in the tyres industry.
In these machines, something goes wrong almost all the time. Also, these machines are depending on each other's proper operation, in a similar way to a web browser.
Since PLC works in a very logical way, I found it very simple to write the program; I just needed time. Most decisions in a PLC program are taken only based on Boolean flags, which makes the program very clear.

I don't know why computer program has to break its own logic and fall into a dangerous game of throw and catch. In more critical programs, such as PLC programs, this considered to be the most non-robust behaviour.

Programming a PLC is different then programming computer, in a way that the program must work; and if it doesn't: you call the programmer back to finish his work. Machines don't understand bugs, and improper behaviour of machine can cause a big accident.

Pete gives an example of x = y[z]. Out-of-bound and not initialise variables happen anyway, with or without exception handler. This is the main difference between PLC programming and computer programming; In PLC programming the programmer must take responsibility for his mistakes ("bugs"), while in computer programming bugs are part of any program.

I used error handling in QuickBasic many times before, because QuickBasic don't supply returned error codes - it simply crashes.

Using error handlers in QuickBasic was the worst experience from that language. And at those days QuickBasic worked on DOS(!).
Fatal error such as "Illegal function call" is a bug that I, the programmer must fix - not a pathetic error handler that sends the user back to the main menu after two hours of hard work.

Fatal error such as "Drive-not-Ready" are the most ridiculous; Drive not ready - so what??? In PLC programming if a digital sensor tells me that the tank is not empty then my program simply waits until the timer stops, and then turns on a red light on the control panel. that's it. simple.

Computer is a machine. And it may be connected to other machines. Checksums, error codes, and branching statements are much more solid and robust programming behaviour, for truly critical operations. That's why there is no "fatal error" in PLC, since PLC should never stop its operation. There might be an adjustable watchdog that continuously test the proper operation of the PLC (similar to computer BIOS chip), and stops the PLC in case of improper operation - but PLCs are built to be reliable and robust.

From my personal experience error handler is the hardest to write and the most fragile programming method. It also forces the programmer to use it - as in QuickBasic - even if he really wishes to avoid it.

I really don't understand the answers since my experience proves the opposite...

42. Re: Try/Catch

• Posted by Shian_Lee Jan 07, 2015
• 5924 views

My experience comes from working 10 hours a day since I was 14 years old.

And I still think that your last answer is avoiding my question.

Any sane human being knows that ANY machine, including PLC, can fail. And in the PLC area there are many methods and backups for this case, yet accidents happen, and yet many programmers and electricians are careless.

I am offering here to consider error handling from a different point of view. Take it or leave it.

Excuse me of being rude, but I wonder where your experience comes from.

44. Re: Try/Catch

• Posted by Shian_Lee Jan 07, 2015
• 5891 views

Let's stop this nonsense.

You have two basic ways:
1. exception handler.
2. error codes from routines.

That's all I can think about. Choose your way.

Time for Taekwondo now.

Bye and thank you.

46. Re: Try/Catch

• Posted by petelomax Jan 07, 2015
• 5898 views
• Last edited Feb 16, 2015

I concede. Once I thought of it, catch e ... throw(e) is a fairly compelling argument.

Here is a first stab at defining what an exception innards might look like (with something of a Phix bias)

catch e

The following constants can be used to examine the contents of an exception

1. E_CODE (atom) hardware and operating system exceptions usually have bit #800000000 set, user exceptions can be any atom value.
2. E_ADDR (atom) a machine address indicating where the exception ocurred
3. E_RTN (integer) equivalent to routine_id(), an index to the symbol table identifying the routine (optional)
4. E_LINE (integer) the source code line matching E_ADDR in E_RTN (optional)
5. E_NAME (string) the human-readable name of E_RTN (optional/may be integer)

Only the first two elements are guaranteed to be present. Further user-defined elements may also be present. There is no upper limit to the length of an exception or the amount of detailed information it can contain, however the first five elements have predefined meanings.

throw(object e, object e6={})

if e6!={} then e must be atom and throw(e,e6) is equivalent to throw({e,-1,-1,-1,-1,e6}), modified as below.
if e is an atom, throw(e) is equivalent to throw({e,-1,-1,-1,-1}), modifed as below.
if e is a string, throw(e) is equivalent to throw({0,-1,-1,-1,-1,e}), "" (probably Phix only, and same as throw(0,"string")).
Otherwise e must be a sequence containing at least the first two elements, E_CODE and E_ADDR, type safe as above and any user-defined data in e[6..$].

• if e[E_ADDR] is -1 it is replaced with the return address from the throw() call.
• if e[E_RTN] is -1 it is replaced with a routine number from the current call stack.
• if e[E_LINE] is -1 and e[E_ADDR] was -1, then the (new) value of e[ADDR]-1 is mapped to a line number in e[E_RTN] and stored in e[E_LINE].
• if e[E_NAME] is -1 and e[E_RTN] was -1, the name is retrieved from the symbol table, however (in Phix) that will be a meaningless ttree index when interpreting and a proper string only when compiled.

Note that for hardware and operating system exceptions, e[E_ADDR] may correspond to a machine instruction emitted for the source code line, or the first byte of the next line, or somewhere deep in the heart of say kernel32.dll, or part of the internal workings of c_func, and therefore (in early versions at least) e[E_LINE] may be quite wrong. Such cases will need to be fixed on an ad hoc basis, either by subtracting 1 from e[E_ADDR] for selected e[E_CODE], emitting a judicious nop instruction, or hunting about in the call stack for the first thing that makes sense. If all such efforts are in vain, the runtime reserves the right to give up and return a two-element sequence. In short, you should not become over-reliant on the optional values e[E_LINE] and e[E_NAME]. You can however populate a throw() statement with made-up values.

Let me know if you have any ideas, I'd prefer not to introduce unsurmountable incompatibilities.

Pete

edit (one month later): just noticed I missed out the constant E_USER=6.

48. Re: Try/Catch

• Posted by andi49 Jan 07, 2015
• 5867 views

Hi

what is your problem?

You do not like excetpion handlers? So, don't use it. That's all.
Don't like 'goto'? Don't use it..
Don't like 'OOP'? Don't use it.

For PLC's there is now CodeSys V3, used by over 300 mostly small to medium manufacturer, on the market since about 5 years.
It does support OOP and exception handling. But you do not have to use it!. You can still program like in the 80's
Even S7 from Siemens support this.

Giving people the freedom of choice is very important (from my point of view).

Go to the PC side (mean Desktop Computer). FPC (FreePascalCompiler) supports OOP and Exceptions and Standard Errorhandling.

But again, you do not have to use it...
You can still program like 30 years before, it works...
FPC gives you the choice.
It also supports a DOS Compiler.

Most of this is also true for FreeBasic, even Phyton (ok, no dos) etc.

Euphoria is really nice, and easy to use but a little evolution want hurt it.

Giving the People the choice to choose what they want is is really important.

Andreas

50. Re: Try/Catch

• Posted by jimcbrown (admin) Jan 07, 2015
• 5837 views

The concept is sound and it'd be easier to implement. What's not to like?

The issue here would be, in dcuny's original example, that there is still no way to handle 'x = s[i]' effectively without having the program (eventually) crash. This is still an improvement (as least you have a last-ditch chance to save any unsaved data), but you can't deal with unexpected exceptions and pick off from where you left off. Maybe that's a good thing.

Still, I don't think it'd be technically hard to make it so that, if all trap handlers return the OK result, to return control to the following statement or something... maybe one could specify a goto label along with the trap handler routine id, that would only be used if the trap was triggered within scope of that label. So, we can make this more flexible. (Not saying that we should, necessarily, just that we can if it is decided that that would be the way to go.)

We already have crash() for that. Or do you mean a resume_trapped_ex() which could only be called from inside the trap handler?

52. Re: Try/Catch

• Posted by mattlewis (admin) Jan 07, 2015
• 5839 views

Sounds like crash_routine().

Matt

54. Re: Try/Catch

• Posted by dcuny Jan 07, 2015
• 5827 views

Imagine I've got a program that generates a .wav file as output. I find that someone's written a library that generates .wav files from a sequence.

Hurrah! Only there's the possibility that perhaps the developer didn't do adequate range checking. If we use your definition of exceptions, I've got a couple options:

1. I can read through the library, making sure that it traps all possible errors, or
2. I can write my own library, just in case, or
3. I can choose not to use Euphoria
   
   

While in theory I can anticipate range errors, this is tricky in practice.

I'd rather be using a language that allows me to gracefully recover from exceptions, than one that crashes.

As pointed out, if you chose not to use that feature... you still get an immediate failure.

- David

56. Re: Try/Catch

• Posted by jaygade Jan 07, 2015
• 5879 views

... 
someRoutine(a, b, c) 
if error then 
   -- handle the error 
end if 

-- a typed variable 
atom x = 0 
 
-- don't halt on errors 
on_error_continue(1) 
 
-- do something that causes an exception 
x = "assigning strings to atoms fails!" 
 
if error then 
   printf(1, "The error was %s\n", {error_text}) 
end if 

s1[i][j] = s2[k][j] 

func f() { 
    defer func() { 
        if r := recover(); r != nil { 
            fmt.Println("Recovered in f", r) 
        } 
    }() 
    fmt.Println("Calling g.") 
    g(0) 
    fmt.Println("Returned normally from g.") 
} 

func c() (i int) { 
    defer func() { i++ }() 
    return 1 
} 

What you wrote here is English, but I don't understand any of it.

Where does "on error continue" come in?

someroutine(a, b, c) 

is a procedure which doesn't return any values. So there is no "if error" available.

Euphoria is capable of returning multiple values by design, so I don't understand this post.

58. Re: Try/Catch

• Posted by jaygade Jan 07, 2015
• 5840 views

Why Go gets exceptions right, and C++ and Java get them wrong: http://dave.cheney.net/2012/01/18/why-go-gets-exceptions-right

In Euphoria, the same technique can be used by returning a sequence or object instead of a concrete atom or integer.

60. Re: Try/Catch

• Posted by jaygade Jan 08, 2015
• 5804 views

Summary:

Inputs to a program must be checked for validity or corruption. Bad input should result in an error condition which should be handled as early in the program as possible.

Logic errors in a program should result in a crash and should never escape developer testing; however if they do then a crash report should be sent back to the developer. In such case, the program should produce no usable incorrect output to the user.

62. Re: Try/Catch

• Posted by jaygade Jan 08, 2015
• 5791 views

If the developer wrote bad code, then yes, that is the correct behavior.

It did seem contrived. If it happened to you, then the one to blame for the fault is the developer, not the language.

64. Re: Try/Catch

• Posted by dcuny Jan 08, 2015
• 5734 views

This. Especially #5.

+1000

On the other hand, if you want Euphoria to be your own private language, by all means don't implement features common to other languages, and then tell people that Euphoria is superior because it lacks these features. And be sure to cast aspersions on their coding skills while you're at it.

- David

66. Re: Try/Catch

• Posted by DerekParnell (admin) Jan 08, 2015
• 5793 views

Ok, so don't use Euphoria.

However, there comes a point at which one must simply trust the code written by others. You do it already ... how do we know what machine code the C compiler actually generates ... perhaps it could generated incorrect stuff? So with this hypothetical library, it is not designed to fail so if it does, either get it fixed or stop using it. But let's say it failed and your code actually got control at the point of failure ... what sensible thing can your program do to carry on? Basically it boils down to --- don't call the library routine with that same data. You call it with different data but what data? And why would different data not also potentially cause a failure again? Your trust in this failing library must now extended to any call you make to it, thus effectively invalidating the use of the library for anything.

68. Re: Try/Catch

• Posted by DerekParnell (admin) Jan 08, 2015
• 5799 views

Of course it isn't better, but that isn't the argument being put forward, is it?

Let's take just a few scenarios and you can explain what recovery is about.

• You attempt to save the file you've been editing for the last hour, and the editor traps an exception and pops up a dialog window with "** Unable to save file - Retry or Cancel".

• You attempt to save the file you've been editing for the last hour, and the editor writes out random bytes instead and doesn't say a thing. The screen still shows your correct text. This continues a few times until the eventually editor traps an exception and pops up the dialog box with "Invalid character found in file - Retry or Cancel."

• You attempt to save the file you've been editing for the last hour, and the computer's power fails. You manage to power it up again and start the editor but it traps an exception and pops up a dialog window with "** Unable to open file - Retry or Cancel".

• You attempt to save the file you've been editing for the last hour, and the editor saves it correctly. You continue editing for a few more hours, pressing Ctrl-S every so often and it is all going well. Finally, sleep beacons and you close the file. The editor catches an exception - after incorrectly deleting your file on disk, and pops up a dialog window with "** Closing the file failed - Retry or Cancel".

Ok, so I went a bit crazy with these examples. They are all theoretically possible and it could seem that exception handling isn't helping much. I think that putting up examples is not helping either argument. What we need is a compelling argument for why recovery should be an option after an exception occurs - and what exactly do we mean by recovery?

70. Re: Try/Catch

• Posted by jimcbrown (admin) Jan 08, 2015
• 5814 views

Why the heck did we add goto then? Adding a new feature like try-catch isn't forcing new users to use it.

Refusing to add it, however, is the same as forcing new users - who may have perfectly valid reasons to want it - to not use it.

In situations where I've had to gracefully recover from an Euphoria app, I've writen a nanny program and have it watch the other app. If the other app crashes, the nanny program restarts it so it can pick up where it left off.

Agreed. I've seen issues in the past where java.exe itself crashed, blowing the entire app in smoke. At a certain point, there's not a whole lot you can do about it...

On the flip side, why make it worse by forcing us to trust people when we don't necessarily have to? Keeping the number of people who have trusted access to your passwords is a good security practice. Adding try/catch so we don't have to trust the author of a random library as much to prevent our app from crashing in a production environment likewise seems like a good idea.

I think this is unacceptable if it happens in a production environment. The more code there is, the harder it is to test everything.

That doesn't mean you don't try, of course, but remember the adage: all software has bugs. Not "all software that hasn't been thoroughly and appropriately unit tested has bugs" but "all software has bugs".

On the flip side, this means software using try/catch also has bugs and can still crash. try/catch is not a panacea - but I don't see anyone trying to argue that it is.

This I agree with.

By your definition above, I'd argue that these aren't really exceptions - errors, sure, but they're reasonably anticipatible and should be detectable and correctable with an appropriate amount of testing.

Are you talking about after a true exception occurs, or a not-exception like your examples? The difference is important.

72. Re: Try/Catch

• Posted by Shian_Lee Jan 08, 2015
• 5738 views

If you are working for NASA then OOP and exception handler may be welcom in a controller.

Normal people, Normal electricians, Normal factories - using ladder programming.

Nothing is wrong with me, I just live on Earth, while some people are already buying lands on Mars.

74. Re: Try/Catch

• Posted by DerekParnell (admin) Jan 08, 2015
• 5717 views

User input errors are not exceptions, in my way of thinking. User input ought to be validated a soon as practicable upon entering the application.

Wow! Not only annoying, but an example of where exception handling is pointless. So someone went to the trouble of catching an exception that has no effect on the job you're doing with the application. Clever.

76. Re: Try/Catch

• Posted by mattlewis (admin) Jan 08, 2015
• 5743 views

Like any entity subject to the laws of physics and mathematics, your users will come up with ways to use your program that you didn't think of. Or maybe some module has an error in it even with handling correct input. It could be yours, it could be someone else's. Consider this:

Suppose you write a library. In all of your public interface, you implement exception handling, and then you return an error to your user instead of crashing or giving them an exception they might or might not be able to handle. When you encounter these, or receive reports from users, you fix the error so something more appropriate happens. Now people who use your code (probably including you!) can use your stuff relatively sure that your code won't crash their program (obviously, C calls, etc., may be exceptions to your exception handling, but you get the idea) if they encounter bugs in your code.

What's bad about this?

You can think up examples where this doesn't or shouldn't apply, but that doesn't invalidate my hypothetical presented above.

Pointless‽ It stops the program from crashing! There's a module that has an error. Rather than die right there, the rest of the program carries on. Not every situation is like this and should be recovered from, and fail fast is an excellent development paradigm, but saying that all errors should halt the program is sometimes equivalent to hating your users.

Matt

78. Re: Try/Catch

• Posted by Shian_Lee Jan 08, 2015
• 5786 views

Since this bug is already catch in a very elegant way, the user don't even bother to report it; he simply continue his work and this bug will last another few years (as I've seen in many programs).

If the IDE would have crashed, I bet that this plugin would have fixed or removed much quicker. Personally I don't bother to report a bug unless it really bothers me (if the program crashes). And there are so many bugs out there.

As an experienced user, I save and backup my work frequently. I guess any programmer does. Automatic backups are common option in editors, since the developers are realistic after all.

(Don't be offended, I'm just commenting here)

80. Re: Try/Catch

• Posted by jimcbrown (admin) Jan 08, 2015
• 5695 views

On the other hand, the user - after seeing the error crash the IDE - might decide that it's better to move on to another product where this doesn't happen. In any case, forcing users to become assistant developers (by forcing them to write out bug reports) is probably not a best practice... like in Matt's real life example, I'm sure those users have better things to do.

Definitely a sound practice.

82. Re: Try/Catch

• Posted by elias_maluko Jan 08, 2015
• 5705 views

Note that once you introduce something like exception handling in a language, its not a optional thing. Many situations will force, even the developers that dont like it, to use it.

For example: If the fopen() function throws a exception (instead of a error code) when a file dont exists, all developers are forced do write try/catch blocks to check if everything is OK.

Exception handling is not this holy grail you're selling. The same way code can break with a error, it will break with unhandled exceptions.

I dont like exception handling, and think that its not compatible with anything that uses simplicity as a feature (my personal opinion here).

Sorry my bad english...

84. Re: Try/Catch

• Posted by jimcbrown (admin) Jan 08, 2015
• 5681 views

I'm not so sure that this is necessarily true. I don't see anyone being forced to use goto.

Agreed, this is a bad idea. We should not do this.

What would be even worse is that, instead of throwing something or returning an error code, fopen() crashes your entire program if it can't open a file. Now, that would be really bad, wouldn't it?

86. Re: Try/Catch

• Posted by mattlewis (admin) Jan 08, 2015
• 5690 views

I think that for this example, in a hypothetical situation where I was developing try/catch in euphoria, I'd make not handling something like that a warning, not an error. But I would also be very wary of throwing exceptions from built-ins.

Matt

88. Re: Try/Catch

• Posted by dcuny Jan 08, 2015
• 5758 views

As I (and others) have noted, Euphoria is basically designed as if the end user were a developer.

So the program crashed? No big deal, read the crash report and fix the program. Hurrah - one less bug in the code.

But our end users shouldn't be treated as if they were testers who "should" report bugs.

As far as end users are concerned, if the program crashes what they "should" do is never use the program again, and warn their friends about how terrible it is.

- David

90. Re: Try/Catch

• Posted by Shian_Lee Jan 09, 2015
• 5680 views

I agree.

What I was looking for seems to be more like Design by Contract which offered by Bugmagnet.

Electric equipment usage is based on specifications. If you plug 110V machine into 240V outlet, the machine will not work. As long as you follow specifications it will work.

Specifications are more clear and reliable way to deal with exceptions, at least in the real world.

And I also think that routines must return an error code wherever applicable.

Logical errors in your own program will occur with or without the presents of error handler in Euphoria.

92. Re: Try/Catch

• Posted by petelomax Jan 09, 2015
• 5603 views

Arguments aside, I think the next (small) step, in the investigation process, is for someone to translate eg

puts(1,"started\n") 
--try 
puts(1,9/0) 
--catch 
puts(1,"exception caught\n") 

and then see if they can modify the resulting C code to use setjmp/longjmp and survive.

Then repeat the process with the 9/0 several nested calls deep away, and finally post the C source mods here.

Pete

94. Re: Try/Catch

• Posted by mattlewis (admin) Jan 09, 2015
• 5611 views

The biggest problem, to my mind, is stuff that doesn't call RTFatal in a translation, but gives you a machine type error. For instance, we don't do bounds checking in translated code.

Matt

96. Re: Try/Catch

• Posted by mattlewis (admin) Jan 09, 2015
• 5522 views

We know what we need to clean up at the end of a function. We'd just have to know what was still in scope based on different scopes in the function and DeRef it all. Surely not as simple as I make out, of course.

I've had the same thought.

Matt

98. Re: Try/Catch

• Posted by dcuny Jan 09, 2015
• 5599 views

Here's a proposal for something more "Euphoria-like", that might address some of the perceived abuses of try/catch. It's modeled roughly off the pcode() ("protected code") call in Lua.

First, the general form, for a procedure:

-- do something dangerous with a function 
if protected_procedure( scary_procedure(a, b, c) ) then 
   -- handle the exception 
end if 

For those paying close attention, this requires some serious gymnastics on the part of the parser. That's because normally, the argument list is processed before the call to the routine. I'll hand-wave this away for the moment, and get on to the next case: calling a function.

The call to pcode() in Lua looks something like this:

error, theta = pcode( sin(x) ) 

This doesn't work well in Euphoria because Euphoria doesn't know if a sequence is coming back as a single value from the function, or a list of parameters from the function.

And there's a subtle point here: assignment should be conditional. If the call to the function resulted in an error, the assignment shouldn't take place, because the result (if any) is likely to be bad.

I think we can kill two birds with one stone here:

-- do something dangerous with a procedure 
if protected_function( {x, y}, scary_function(a, b, c) ) then -- safe version of {x, y} = scary_code(a, b, c) 
   -- handle the exception 
end if 

Where the actual assignment of:

{x, y} = scary_code(a, b, c) 

would only take place if scary_code didn't raise an error.

Behind the scenes, it might generate code that's roughly:

-- set the protected_call flag for the frame 
set_protected_call(1) 
 
-- perform protected code 
__PROTECTED_RESULT = scary_function(a, b, c) 
 
-- clear the protected_call flag for the frame 
set_protected_call(0) 
 
-- assignment is conditional 
if not __ERROR_FLAG then 
   {x, y} = __PROTECTED_RESULT 
end if 
 
-- deref the returned value from the temp 
__PROTECTED_RESULT = 0 
 
-- the user's custom code 
if __ERROR_FLAG then 
   -- handle the exception 
end if 

So when RTFatal executes, it unwinds the call stack until if finds a call frame where the protected_call flag is true.

I won't even suggest how this might work in C.

Is this sufficiently Euphoria-like?

- David

100. Re: Try/Catch

• Posted by Shian_Lee Jan 10, 2015
• 5584 views

Andreas,

We like to supply machine with ladder program since it is common knowledge to all electricians. We think what's good for them - not for us.

I'd like to see Euphoria being used by everyone, not only by professionals. I think what's good for anyone - not for me.

Handling exceptions can be done in a more high-level way, which is suitable to the overall usage of Euphoria.
Routines + Specifications that returning error codes may be innovative, clear, and simple programming method for any end user.

Depends on the implementation it may not catch logical/index errors for example, but in my opinion, in case that the programmer is not sure of his own code, adding some if...then to the code has an advantage over presenting a new and complex method of programming in Euphoria.

I'm not arguing here, I just comment my opinion; because as you add more complex programming methods to the language, you ignore the basic concepts of Euphoria which might give a good reason to many users to immigrate to another popular language. (I don't say don't do it - I say do it as innovative as Euphoria itself).

102. Re: Try/Catch

• Posted by useless_ Jan 10, 2015
• 5507 views

x = s[length(s)+1] 

Choose a soft and gracefull fail, and it will do what the filesystem does: extend the sequence and return a {} or a null. Maybe a default exception handler which you can append your exceptions to. I have asked for this for years, there's no reason an interpreter should nuke itself over this. In my opinion, which is useless.

useless

104. Re: Try/Catch

• Posted by jimcbrown (admin) Jan 11, 2015
• 5502 views

Perhaps that should be changed.

Not all do, however. Remember "sequence found inside character string" for puts() and somesuch?

x = s[length(s)+1] 

The only reasonable solution I can come up with (outside of pcode or try/catch that is) - add a special index_crash_routine() for this case, and if a handler is defined, call it with the sequence and the index and let it figure out what to return (or alternatively to crash). If no handler is defined, crash. But then you'd probably have to come up with similiar functional_crash_routine()s for each category of errors that can't be handled by a return code.

The easy way out would be to set a global errno and leave the value of x unchanged, but I think it's obvious why no wants to do this.

Looking at the example bugmagnet came up with, that framework would throw a Throwable: https://github.com/andresteingress/gcontracts/blob/master/gcontracts-core/src/main/java/org/gcontracts/PreconditionViolation.java

At least in bugmagnet's example, Design by Contract is used as part of the fail fast philosophy. Which, as I've said before, may be fine in development but not so much in production.

Using ... Throwables ....

Not in bugmagnet's example, which states that the two pieces of java code are identical:

<pre> def start() { if (started) { throw new AssertionError("Rocket already started!") } def oldSpeed = speed speed += 10 started = true if (!(started   speed - oldSpeed > 0)) throw new AssertionError("Rocket not }

@Requires({ !started }) @Ensures({ started   speed > 0 }) def start() { speed += 10 started = true } </pre>

Right, but that brings us back to the earlier discussion about third party libraries.

In Bugmagnet's example (gcontracts), it appears to be necessary for this to be done on each routine individually.

Even if you could specify a specification for an entire module, you would almost always want to add individual specifications to each routine anyways...

106. Re: Try/Catch

• Posted by Shian_Lee Jan 11, 2015
• 5474 views

I would say that:

include foo.e with spec -999

automatically applies 'with spec -999' to all routines in the plug-in module, and for the entire module. i.e. as soon as any routine is called - a module level exception will force it to return -999, which should be validate by the calling module as usual, using if...then.

just a very raw example for Specifications for the whole module.

108. Re: Try/Catch

• Posted by jimcbrown (admin) Jan 11, 2015
• 5399 views

I have some reservations about doing it this way. However, in the interests of furthering the discussion, I've implemented this (with the integer value of 0 representing null) in the equal branch: http://scm.openeuphoria.org/hg/euphoria/rev/1d9b443bd04b

Edit: Actually, just the two interpreters (C and Eu backends). I haven't tried to fix up the translator, since as mattlewis pointed out it would be a bit harder (since we're not even always doing the necessary bounds checks in the first place).

110. Re: Try/Catch

• Posted by useless_ Jan 11, 2015
• 5442 views

This is why i said "choose". In the case you gave of the string being indexed out of bounds, the programmer should know there is no {} in their string. Getting a {} back indicates an error, but i would assume that in indexing by atom in that string, the programmer is looking at each atom for some reason, and would recognise a {}, and perform code accordingly.

If Eu provided a switch for "fail gracefully" or "crash dead", then you choose. I think it beats the programmer wrapping each and every variable access in bounds-checking code (which slows things down), which the compiled Eu intentionally doesn't do (so as to speed things up). For the example you gave.

useless

112. Re: Try/Catch

• Posted by useless_ Jan 11, 2015
• 5404 views

Not necessarily. In the examples given of crashes, where a loop var is the length of a sequence, and inside the sequence the length is shortened, one could argue for the loop var not being cached. This has not been accepted by the developers of the Eu core.

Because that is wrong. If the sequence is a basket, and the table is memory space, and i ask for the item on the table that is simultaneously the last thing in the basket, the answer isn't the last thing in the basket. The most correct answer (to avoid a crash when you have no try/recover) would be a $null, which the programmer can detect as an obvious error, but that's not acceptable in Euphoria either. The next best would be a "", but that isn't acceptable either.

That's fine for the programmer developing the app, but it's not good for the end user. You may as well just crash with that message. There's several ways asked for to get around crashing. None are acceptable to the powers that be. Forcing the programmer to write bound-checks to each and every loop in each and every program isn't user-friendly, and stomps all over the concept of the compiled code intentionally stripping bounds-checking to speed up the crashing. I cannot help but think that DCuny has the same requests he (we, other people, etc) have made since the days of v2.5. We seek improvements to the core that we cannot add as include files. And i fear his (our, etc) requests will be as useless now as then.

useless

114. Re: Try/Catch

• Posted by Spock Jan 11, 2015
• 5419 views

.. and hopefully never will. In the meantime it remains a programming error.

Yes, it is wrong but at least the program don't crash. What is right? Unless the programmer specifies the treatment in such a scenario there's no way the computer can figure it out. And if the programmer specifies it then he should really have corrected the bug that lead to that scenario in the first place.

If the programmer can detect a $null, he should really be detecting the index error instead since that is where the bug is. What place then for $null ?

Not so. The warning could advise the user that a serious error has occurred and suggest that they might save any data and shut the program down. A more sophisticated approach could also record a log file to be sent to the programmer.

You overstate the problem. The vast majority of loops in a program will be plain enough to not require any such checks.

You sure got that right .. Muahahaha!

If you're up for it you could always write your own core. That's what I'd like to do .. one day.

Spock

116. Re: Try/Catch

• Posted by Shian_Lee Jan 12, 2015
• 5416 views

Yes, I do have to catch it in the function level - but only in the low-level implementation. The high-level implementation will only return error codes.

1. Developer needs to do some deep thinking before implementing new ideas.
2. Use only functions to deal with exceptions - not procedures.
3. Return value from function is already part of Euphoria - why introducing a new and complex programming method to the end users? (and overhead is part of any high-level programming technique).
4. Honestly, David, dealing with exceptions, using any possible method, is an art - it can never be done in a standard way. For example, in Assembly, when Carry Flag is set then what your program is doing?... It's only depends on what the program wants to do. It's like an art.
   So using error codes is the same, it's just that the end-user is already very-very familiar with this simple approach. When you really afraid of a specific indexing situation - place it in a different function which returns your desired error code (object).
5. if...then is used everywhere anyway. It's less confusing then try/catch. In case I must call a function 1000 times, from too many places, I'll use another procedure or function to call that function, with the proper if..then. I already do it in these cases.
6. I believe that dealing with returned error code immediately, is a much more reliable/logical technique. It might force some programmer to change their programming habits. Personally I believe that logical approach is more "Euphorian" then complex approach, which might be common in other languages. I don't offer something new to Euphoria: open(), dir(), seek(), etc, already using this approach, and we already using if...then to deal with it very clearly and easily.
   
   

p.s. If you felt insulted by me in previous posts... I'm sorry. It surely not your fault, it's all my fault since I'm a bit aggressive (my wife has to remind me that 30 times a day). So sorry.

118. Re: Try/Catch

• Posted by Shian_Lee Jan 12, 2015
• 5380 views

There are minus and plus for each technique; exception handler and returned error codes.

Try/Catch has also its minus, for being a complex method, not so "Euphorian" in my opinion.

Both minus and plus of each method should be considered by the developers...

I vote for Simplicity, since it's a core concept of Euphoria programming language.

Edit: I prefer the general approach of open(), which doesn't tell me anything about the real problem (file-not-found/drive-not-exists/etc), because all I care about is if the task is done or not. Simple approach.

My personal programming style never make use of error handling, unless it's really necessary in some very specific situation. Big programs that I wrote (for salary calculation, work management, etc) without using a single error handler, served for many years.

I think that exception handling should be used as less as possible, or not at all, in a well written program. (Personal approach).

120. Re: Try/Catch

• Posted by jimcbrown (admin) Jan 12, 2015
• 5285 views

Not a bad idea, but he hasn't posted on this forum since December 2010. He seems stay out of development these days, enjoying his retirement I guess.

While RobCraig's opinion would be helpful, it's not definitive. Remember, goto was added to the language even though RobCraig opposed it.

Start coding, and posting the new code. The sooner we have code to grit our teeth on, the sooner we can get it finished.

122. Re: Try/Catch

• Posted by Ekhnat0n Jan 12, 2015
• 5279 views

WHAT IF:
like I stated under The Strengths of Euphoria

I myself, assisted by a number of "old hands" would try and convince
Robert and his wife to enter into the discussion?

I am pretty sure we can find support somewhere else though I can't tell you about that issue YET

but I have a solid idea where to find such help

124. Re: Try/Catch

• Posted by dcuny Jan 13, 2015
• 5311 views

I'm not sure I see anything about try/catch that can be seen as "abandoning your own obligation."

Euphoria currently has no mechanism for recovering from exceptions.

Yet this is a feature that is expected from modern programming languages, because it is simply unacceptable for programs to shut down on errors and exceptions. Part of this expectation comes from the fact that other modern programming languages do handle exceptions and recover.

Because this is a reasonable expectation, the question is not if it should be done in Euphoria, but how it should be done.

That's the context of introducting try/catch.

So, what's wrong with other approaches?

Consider your with spec example for a moment:

function foo(sequence s) with spec -999 
    return length(s[1..$ - 5]) > 2 
end function 

In order for this to work, you need the value returned from foo to be one of two types: a valid value, or an error indicator.

Guaranteeing that your error value will never appear in range of acceptable values can be tricky, as anyone who's written code where the eof is indicated by -999 and then had that value appear in the data file can attest.

And that ignores that what constitutes an error flag will obviously change from routine to routine.

So at a higher level, you'll end up writing code that includes "magic numbers", which is always bad:

result = foo(s) 
if result = -999 then -- magic number 
    -- handle the error 
end if 
 
result = bar(s) 
if result = 99999 then -- another magic number 
    -- handle the error 
end if 
 
result = frotz(s) 
if equal(result,{-99999}) then -- yet another magic value 
    -- handle the error 
end if 

Obviously, you should define these "magic numbers" as constants. But since they can (potentially) change from routine to routine, how do you identify them?

Also, (as has already been mentioned), this solution only works with procedures, which makes it impractical.

But there's another problem: you have to make an error check after every routine call "just in case", or you'll miss an error condition.

And that isn't "simple."

In contrast, try/catch solves the problem much more elegantly. When an error or exception is encountered, it pops the call stack until an error handler is found, and then attempts to recover from the error.

Importantly, if there is no try/catch, the program behaves exactly as it does today. This means that you aren't forced to use this solution, and old code continues to perform as expected.

Compared with other solutions for recovering from exceptions, try/catch is simple, and flexible and easy to learn - all of which are (according to RDS) core features of Euphoria.

But if someone can come up with a solution that better fits these constraints, I'm all ears.

- David

126. Re: Try/Catch

• Posted by dcuny Jan 13, 2015
• 5295 views

I agree that foreseeable results should return error values, not exceptions.

I also agree that defensive coding is the best approach. Especially with Euphoria, where the sequence is the core datatype.

And relying on try/catch isn't a panacea. If it's triggered, it generally means that some portion of an application failed to execute properly.

That's bad, and needs to be avoided.

By way of analogy: try/catch allows you to keep running on three wheels when a tire has blown out.

- David

128. Re: Try/Catch

• Posted by jimcbrown (admin) Jan 13, 2015
• 5224 views

One thing try/catch does better is that if you forget to add a check, then the program crashes - so you get fail fast development. Your version doesn't seem to have that (unless you're suggesting that the interpreter crashes when it detects somehow that ERR is set but the caller doesn't check it).

130. Re: Try/Catch

• Posted by andi49 Jan 13, 2015
• 5212 views

Hi

I do not say 'copy this' but maybe you have a look at how other programming languages handle this problem.

Pascal (TurboPascal,Delphi,FPC) use, since the beginning, a compiler switch {I-/+} or {$IOCHECKS OFF/ON}

In the old days if {$I+} is set than the compiler generates a Runtime Error and the is program crashing.
If {$I-} is set than only an ErrorCode is set, that you can check with reading 'IOResult' (it's a function internally and it's reset after reading it).

Nowadays {$I-} behaves the same way than 30 years before ;) 'except' you have a 'try' 'except' block. Than it raises a exception.

And even inside the 'except' block you can use {$I-} and {$I+} to prevent raising an exception in your exception handling (mixing both error check and axception handling).

So this concept gives you the choice to use Error Handling via results or Exception Handling or mix both. And this concept proofed to be working over decades.

Just to say that you are not talking about Exceptions 'OR' Error Codes. You can have both.

Andreas

(btw. there is also {$R-/+} and {$q-/+} for range checking and overflow....)

132. Re: Try/Catch

• Posted by Spock Jan 13, 2015
• 5209 views

Because the internal routine responsible instead of calling FatalError (or whatever it is) would emit a console message and return a default value (in the case of a function). As mentioned in an earlier post, a more sophisticated approach could be to also record the error in a log file to be sent to the developer, perhaps by way of a user-defined routine.

Spock

134. Re: Try/Catch

• Posted by dcuny Jan 14, 2015
• 5160 views

With try/catch, you could decide what to do, and if the program should continue.

- David

136. Re: Try/Catch

• Posted by petelomax Feb 07, 2015
• 5016 views

While fixing yet more bugs in Phix, I just realised something: there is a whole subset of non-recoverable exceptions.

Sure, if you've got an index out of bounds or a divide by zero, or in fact most things, recovery is perfectly reasonable.

But if you've got heap or stack corruption, then it's game over. There will have to be some, hopefully rare, non-catchable exceptions.

Just sayin,
Pete

138. Re: Try/Catch

• Posted by katsmeow Feb 08, 2015
• 4976 views

I like this stick-in-the-mud statement from 14 years ago:

It's frustrating that such things people wanted from back then, are still not in OE, just because "blah doesn't have it, so i intentionally won't either". Can you imagine how much better OE would be today if OE had simply taken the request list of 15 years ago and put that stuff into OE right away, first thing, OE v1? Yeas folks, it's been 15 years, some of you have gotten married and now have teenage kids now, and OE is still sitting on that statement by Robert Craig (and other statements by other people) way back in the mists of time, pre-smart phone, pre-200GB hdd, pre-multicore Pentiums.

Kat

140. Re: Try/Catch

• Posted by katsmeow Feb 08, 2015
• 4943 views

Jim, coincidently, i am listening to Tracy Chapman, a singer, who performed on a small stage i set up in Atlanta ~1986. That was 29 years ago, and the words of the song sound like they were written of the Ferguson murder of 2014, or nearly every day in every city and town today. My point is that waiting patiently accomplishes nothing. People are still asking what they asked for 15 years ago, and near as i can tell, we will still be waiting tomorrow and the following year.

So in OE, before calling any function, write where we are going, to a reserved space. For kicks and giggles, point a variable name at it, maybe that will be useful tomorrow, by someone who discovers OE tonight. Thereby, when there is an error, we will know where we came from, we can back up to a point perhaps we can resume executing, where the error is irrelavant. If nothing else, the error msg can be more illuminating.

It took all of a few seconds to figure how to do this with no speed hit on a 6502 system: watch the cpu's SYNC line, have a latch grab the interesting instructions and/or addys, store them to a section of ram somewhere, then inc the pointer counter. Memory map the whole couple of chips to somewhere, and point a variable at the pointer's output. Presto, you have a log of the previous interesting machine code addresses hit, and you incurred no performance penalty while doing so. My point being: sometimes the old way of doing things, and thinking well outside the box, can do seemingly wonderous things, with no waiting.

Kat

142. Re: Try/Catch

• Posted by Spock Feb 09, 2015
• 4917 views

I don't think there was any move towards a general acceptance of try/catch. The problem of programs aborting prematurely could be dealt with in a much simpler fashion using a local builtin error/status code. The change to programs (and Euphoria) would be minimal. It would have helped to sell the idea of try/catch if there had been good examples showcasing genuine advantages (over smart status code). I don't recall seeing any.

Spock

144. Re: Try/Catch

• Posted by jaygade Feb 10, 2015
• 4851 views

a = s[BAD_INDEX] 

This kind of error should crash. It's an unrecoverable error/probable logic bug by definition.

if BAD_INDEX <= length(s) then 
    a = s[BAD_INDEX] 
else 
    -- handle error condition 
end if 

146. Re: Try/Catch

• Posted by dcuny Feb 10, 2015
• 4833 views

If you're referring to:

Perhaps I should have been more clear with my language.

By "error code", I mean a returned value from call that indicates there was a problem executing the routine. As an example, if an open() routine fails to open a file, it returns an error code instead of a valid handle.

By "recover", I mean that the code stops executing code at the level where the error took place, and returns control to a higher level in the execution stack, which can act on the error condition.

Returning "the element nearest the index value" is only the correct action to take in a very narrow set of conditions.

Likewise, assuming that the end user will be knowledgeable enough to understand a console warning message is very unlikely.

Your solution effectively ignores the error condition, and continues execution despite knowing the result of the operation is in error.

For that reason, it fails to match the criteria.

- David

148. Re: Try/Catch

• Posted by Shian_Lee Feb 10, 2015
• 4807 views

try/catch is probably the best solution. but it's not part of the Euphoria philosophy. it's not part of Euphoria at all. it's not simple. period.

if you implement try/catch for best response, then why using atoms? wouldn't it be much better to use integer, long, double, unsigned/signed, maybe nibble? why not in-line C code? I am not exaggerating - Euphoria has and should keep it's own identity/personality.

I assume that some modern Basic dialect could do the job very well. But with lots of built-ins and options, almost as C...

The idea of Euphoria is to be minimalist, readable and simple - so you'll be able to write reliable code, much more then C or Basic, therefore you don't really need error handler to wrap any block of code for just in case.

150. Re: Try/Catch

• Posted by katsmeow Feb 10, 2015
• 4804 views

Sadly, we DO need to wrap everything we do in error checking. You just cannot do "s = x[y]" because eventually it will crash. You must wrap it in bounds and length tests. Chances are, eventually when munging real life data, 'y' will be greater than length(x), or 'y' will be less than one, or x[y] will be a nested sequence, or 'x' will be "". Something will be wrong, and you must guess what all chances of crashing are, and code against them. You may say that makes for good coding, but i think it certainly isn't simple and minimalist coding.

Kat

152. Re: Try/Catch

• Posted by katsmeow Feb 10, 2015
• 4804 views

I believe Rob is saying that since no other langage or OS has a feature, it should not be in Euphoria either. I feel the other way, that along with sequences, Euphoria should have other rare features, and other useful features.

Kat

154. Re: Try/Catch

• Posted by dcuny Feb 10, 2015
• 4780 views

No one is advocating intentionally writing buggy code.

With all respect, a web browser is many magnitudes more complex than your QuickBasic program. Additionally, it relies on many library components (graphics rendering, handling plugins, memory management) that are beyond the control of the developer.

Having an attitude that people should be able to write programs that are "simply not buggy" is unrealistic.

- David

156. Re: Try/Catch

• Posted by jimcbrown (admin) Feb 10, 2015
• 4744 views

And yet, I use lynx to browse and post on the forum.

158. Re: Try/Catch

• Posted by mattlewis (admin) Feb 10, 2015
• 4740 views

But what are those? Anyways, if I judge it worth it to me to work on something like try/catch, I'll probably do so (assuming there isn't some consensus that we definitely shouldn't do that, which I don't think there is).

I'm definitely interested in what people think is an interesting or worthwhile feature to have. I'm a lot less interested in others' estimates of LOE required to get those features. There are some 4.0/1 features that required a heck of a lot of work that I wouldn't want to live without any more. I can definitely imagine a time when try/catch is one of those.

Matt