Try...Catch possibility?

It would be nice to have that possibility in newer versions of Blitz3D, as in some cases, you can meet unexpected access violations which you can't avoid by using other commands to test if it can be done, before you actually do it.

try
  Graphics3D(800,600,32)
catch
  try
    Graphics3D(640,480,16)
  catch
    Graphics(640,480,16,2)
    dlg=CreateCustomDialog("Error","Unable to set 3D graphics mode",pos_screencenter) ;this is a custom function
    while not KeyHit(1)
      DrawCustomDialog(dlg) ;this is also a custom function
      Flip
    wend

    end
  end
end

In that way you can also have custom ways to show or handle unexpected errors. Wouldn't this be nice? As Try..Catch is a way to handle exceptions in VB. It's named Try..Except in Delphi.

Added: Btw, this is my 300th post :D!!

Yes error checking is a necesity.

I agree it would be useful..

but for your example it can be achieved using

If GfxMode3DExists (800,600,16) 
Graphics3D 800,600,16 
Else 
RuntimeError "Unable to set 3D graphics mode"
EndIf 

Try
Catch
Throw
Lock

I'm familiar with these commands in Cold Fusion. However, the current workarounds for Blitz3D are very easily to implement.

I would love a a command like Visual basic has;

on error goto fixit
or even better
on error fixit(errorcode)

Completely, utterly, totally incorrect. How do you catch 'object does not exist' error? Or an 'entity does not exist' for that matter. Try...Catch handles ALL errors, and it's wonderful for generating error reports.

Michael R,

Is it not true that Try...Catch is merely a If..Else condition for 'any' error. IMHO it is not difficult to perform conditional checks for 'specific' errors.

Ultimately, it is better to isolate and eliminate the trouble that would generate an error in the first place.

Michael:
Having something like try catch for entities would be a bad idea.

Here's why.

Let's say I create an entity. It gets stored at memeory location 1000.

I then attach a particle emitter to this entity.

The entity at some point gets deleted but the particle emitter is still attached to it.

Here is where an entityexists function would come in. Try catch would perform the same function.

But the problem is that all such a function does is look at the memory address specified, and sometimes, it can determine that that location is not an entity.

But that it is not reliable. Sometimes the data there would suggest the object is an entity, and cause a crash as a result, with no indication of why.

Even if Mark is keeping a list of all allocatated entites and their memeory locations so he can tell if a mmeory location does contain an entity that is currently allocated, there is still a problem.

One could conceiveably allocate an entity, delete it, then allocate another entity with a different mesh, which ends up at the same memory location.

There is then no way for Blitz to then know that the entity it finds at location is not the original entity that was allocated.

One can assign a counter to each entity that is created, but that only delays the problem. Admittedly, it is very unlikely that a long int counter combined with the memory location, being used to identify whether said entity exists, would fail... But it's still possible... You'd have to create four billion entities, and keep the majortiy live... Another unlikely event, but still possible.

I can't say why Mark has chosen not to implement EntityExists, but if he has chosen to do so because it is impossible to keep track of enetities, or because he does not want to enocurage poor programming practices, it seems hiughtly unlikely that he would implement this try catch thing.

Er, all that typing for no reason at all. Try...Catch is a great idea for entity not existing errors, and indeed everything else. The point is that it can be used to gracefully report errors to the end user. Stop reading too much into what I am saying - I didn't imply that you would use it for creating an EntityExists( ) function.

Your maturity overwhelms me.

And the amount of time it took you to write a single sentence... considering that I wrote that message, then erased it thirty second later, then checked the forums fifteen minutes after that seeing no reply from you, overwhelms ME. :-)

What do you type 40WPH? :-)

Ouch Swift.

No, it's not true. Throwing an exception breaks the normal program flow (but in a "structured" way nonetheless), and you can catch it at whatever place you want.
When you want to handle gracefully all error conditions, if you do it with return codes you can come to a point where your code is cluttered with error checking -> cumbersome, hard to read and maintain. With exceptions this is not the case, you just handle the error at the appropriate places. But with exceptions too, you could handle the error at any place it can appear, that's your choice and depends on the context (and actually even then exceptions are often clearer).

This, is pretty true. But there are 2 kinds of "errors": the conditions that should never ever happen and should ideally be detected by asserts. The other case, "normal errors" are the ones you seem to talk about. For these excpetions are fine. What will you do when you detect the error? Often you will have to report it to the calling function, that will report it to the callling funciton etc. Instead, just do some clean up and throw an exception, done.

SSwift, I am interested to know too why 'EntityExists' has come in the equation? Pretty bad example actually. Not to say you argue about the difficulty for Mark to implement it, and not the actual benefit you would have with exceptions. Your example:In C++, where the issue is the same, you don't have neither exceptions automagically throw when accessing a deleted object. So what?
Exceptions are still there, and very very usefull I must say.
Now in Java, which uses a garbage collector, you simply can't have dandling pointers, a reference always points to a valid object (...and if I'm not mistaken Mark is seriously considering garbage collection). Is it enough to handle all errors? Surely not.

The dandling pointer error is simply not the worst that can happen, there are tons of application specific errors that can be gracefully handled via exception handling.

Question 1 is: would blitz benefit as much of exceptions? I don't know. Would be nice though.
Question 2: Won't it be disturbing for beginners? Probably.
Question 3: isn't it too complex for mark to implement it? Most certainly, this is not trivial.

Personnaly I don't think Mark will ever add a general purpose exception handling, but I'd be glad to be wrong.

I never said it was. As long as the function throws an exception, Try...Catch can handle it, though.

try..catch is a very easy to implement error handling interface. I have used it extensibly in Java with great sucess. It can be used for end of file detection, Incorrect variable conversions, Index out of bounds checking etc etc..

If it would not be too much effort i would definately nominate it to be included in blitz..

Theirs no real argument here... A program should NEVER fatally terminate in an unexpected manor. I just can’t fathom why any one would say implementing general error handling is a bad thing?

Error Handling is really a OO concept, and thats why that many blitz programmers dont think that they sould need this.

I think it could be great to have, and would make our applications to run better in a exeption environment, and give a better fell for the user.

But that me, im into that blitz becomes 100% OO, so that just me :-D

Exactly. The program can appologise to the user, as well as dump the stack trace which can be sent back to the programmer for analysis. Infinitely better than "Memory Access Violation".


It's not really an OO concept. C has try...catch. It's more that the 'new' generation of really strong OO languages (Java, C# etc) relies strongly on it.

Even BBC BASIC from 1981 could pick up error codes.