Go Here

ThankYou.

---

(:

  A Newly discovered computer term, the opposite of GoTo. 
  When inserted in code, the compiler is put on notice that it should Go Here, dependent onwhat follows, such as:

  GoHere from Beginning
  GoHere on Exception
  GoHere from Error
  GoHere toTest
  GoHere When Exiting  

:)

Notice new emoticon, indicating beginning of spoof and end of spoof

On second thought - this may be a viable candidate - what are your thoughts?

Well, far from being "new", it's been invented quite a couple of times already; I've heard it most often referred to as "ComeFrom". GoTo and come from result in similar lack of readability: GoTo makes an invisible point in program text to which the flow can jump from anywhere, come from makes an invisible point in program text from where the flow can jump to anywhere. Contrary to popular beliefs, come from does not result in significantly less readable code than GoTo. -- PanuKalliokoski

---

Actually, GoHere on Exception, GoHere on Error could be useful constructs. I've often thought it would be nice to have a global exception handler which invoked immediately on exception without unwinding the stack. Potentially, the exception could be handled and the code could be restarted from some arbitrary point. I understand that some SmalltalkLanguage implementations allow this.

What about the POSIX signal() call? A signal does not disrupt the main thread of control.

GoHere for Test would be immensely useful. When browsing through code, particularly in running code, I've wished for some way of knowing what unit tests are available to exercise some given routine. UberReflectiveEnvironments might be used to automatically map backward from application code to the unit tests exercising it.

Two entry points. Every function name is a kind of "comehere to<dosomething>" instruction.

Actually - this was quite popular in 1980's HomeComputerBasic?'s:

 50 ON PEN GOSUB 500
 60 PEN ON
 ..
 500 REM PEN ROUTINE
 ...
 550 RETURN

QBasic (if not many other variations on BASIC) had a generic exception routine called ON ERROR:

 10 ON ERROR GOTO ERRORHANDLER
 20 ON ERROR RESUME
 30 ON ERROR RESUME NEXT

Line 10 popped out to an arbitrary position in the code which could use RESUME or RESUME NEXT, or continue executing until termination. Line 20 retried the statement that caused the exception (I don't remember if it would double-fault and abort the program on a second error.) and line 30 simply ignored the error and tried the following statement.

---

You could implement this using a MethodObject, actually, with a little cooperation from the sources...

 {
  MethodObject errorMethod;

  public void doOnError(MethodObject method){
errorMethod = method;
  }

  public void errorCausingMethod(){
try{
someOperation();
}catch (SomeException error){
errorMethod.invokeWith(error);
}
  }
 }

---

Perhaps this should really be called "ComeHere?"; 'go' is usually said at the source of the movement, 'come' at the destination.

---

Related to: ComeFrom

---

An idea for GoHere--make it Go....Here, like

if x == 0 then go
(lots more code)
here

Way more obfuscation possibilities--especially for nested things like

if (x) go;
blah blah;
blah blah blah;
if (y) go;
blah blah;
here;
blah;
here;
blah blah blah blah;

Now which Go matches which Here?