Plans, Executive (Dys)function, and Throwing Exceptions

I've written before about plans and routines, where a routine can become an implicit plan, and if a plan gets thrown off, I'm going to have a bad time. I've also (really recently!) written about "independent" (as defined by able people, not as defined by the independent living movement) living, supports, and teachable skills not being all there is to it. Now I'm writing about something that connects both of these, thanks to Avi for providing the word to describe it: Exception handling. Thanks to Avi also for the idea of writing these out as scripts. I've done enough programming to write psuedocode for this. Think "vaguely Python-like". The code is intentionally a bit messy because, well, the way my head actually deals with this stuff is a bit messy. So there's exceptions and different kinds of loops mixed together, and sometimes things will just crash instead of doing what you'd expect, even if it's not immediately obvious why.

I've done a little bit with programming, enough to know that sometimes you can break a program by giving it input it doesn't expect. If my program is supposed to take a number between 0 and 100 and convert it into a letter grade, which is an actual simple script they had us write when we were learning, it might not give me an output for a number less than 0, a number greater than 100, or an input that is not a number. It also might, but it wouldn't be especially useful output. (It's not a letter grade for an actual score.) Still, the program just sort of ... stopping ... the first time the input is supposed to get used is a very real possibility if the input is wrong or missing.

Something like that can happen with my change of plans issues, and with my getting things done issues. It's even what goes wrong for me on a lot of surveys and popular online quizzes.

Change of plans

self.goto(class);
self.eat(lunch);
self.goto(meeting);

Error: meeting not found.

And then I am done. I don't really have a script to handle that exception, so I crash.

Tentative plans

self.goto(class);
self.eat(lunch);
try self.goto(meeting);
try self.goto(office);
try self.playgames();
while time>5:30 pm;
     try self.eat(dinner);

This time the plan for the meeting is tentative, so instead of "go" it's "try to go" and the script does not immediately crash if the meeting is not found. This is why "no plan" or "tentative plan only" is better for me than "broken plan." Also, there can be lines after the attempted meeting about what I'll do if the meeting isn't actually a thing that's happening.

Note that self.eat(dinner) can time out or get lost at any point in this list, and that any of the items used being missing will throw an exception that I may or may not be able to handle.

Cleaning my room

self.examine(room);
floor.list(objects);
for object on floor;
     try;
          self.pickup(object);
          location = object.properlocation();
          object.place(location);
          energy -=5
          if energy <=0;
               stop;
               return false

     except object.properlocation()==null;
          if energy>=10;
               define object.properlocation();
               energy -= 10;

     except contents(object.properlocation()) != null;
          if energy>=15;
               try;
                    object=location.contents();
                    energy -= 15

self.flop();

And to be clear, this is what the script looks like after a lot of optimization. I did not always have the two except bits that could catch issues. Common places for this program to fail were at location=object.properlocation() because I don't know where something goes, at object.place(location) because there's already something else where the thing goes. These used to lead to a complete crash.

Now I've got some level of exception handling define a new output for object.properlocation() or interrupt and choose a new object to move because location is occupied. That's what the exceptions are meant to handle, but you might notice that they are expensive! (You also might notice that I can get my energy as low as -5 before hitting the stop point if I'm not careful, which is a problem I'm still working on. If I were actually a computer I could just change some numbers around in my if statements, but I am not.)

I can also run through all my RAM trying to list the objects on the floor and never even get started. This is a thing that happens.

Surveys/Quizzes (must complete, no aid available)

crycount=0   % Initialize the cry count.
for question in survey;
     read(question);

     if question.type()==TF or question.type()=multiple choice;
          answers={true, false};
          if question.type()=multiple choice;
               answers=read(question.answers());
          try answers.choose(correct);
               increment question;
          if "other" is in answers;
               answers.choose(other);
               try answers.write();
          try self.cry();
          crycount+=1;
          answers.choose(leastbad);
          increment question;

     if question.type()==open answer;
          try answers.write(response);
               increment question
          except question.brainbreak==true;
               try self.cry();
                    crycount+=1;
                    try answers.write(nonsense);
                         increment question;
                    try answers.write(nope.explain());
                         crycount+=1;
                         increment question;

     if question.type()==number rating;
          try self.cry();
          crycount+=1;
          random.choosenumber();
          increment question;

self.flop(crycount hours);

So there's two things in there which lead to bad things. It's try self.cry() because I don't always actually cry, but the count definitely still gets incremented and this sort of thing knocks me over  pretty badly. I'm done for the day after even a short inaccessible survey. Multiple choice questions where none of the answers are quite right are bad, especially if they don't have an other option. Certain open response questions also break my brain. I tend to think in patterns rather than examples and my episodic memory is terrible, so if you ask for an example of a thing that happened to me we'll usually get into trouble. Choosing a number to explain how much I agree or disagree with a statement is really bad to start, and it's even worse if the statement is ambiguous or one that I only partially agree with. These kinds of problems, by the way, are why I thought the language utilization reports were the hardest thing they asked me to do while I was in China. They were also the first time I managed to ask for help with one of these, leading to the next bit of psuedocode:

Surveys/Quizzes (not required AND/OR can ask for help)

required=read.survey.required();     % Don't need to check help value because 
                                                              %  this script is only used if help is
                                                              %  available OR completion is optional.  

crycount=0   % Initialize the cry count.

for question in survey;
     read(question);

     if question.type()==TF or question.type()==multiple choice;
          answers={true, false};
          if question.type()==multiple choice;
               answers=read(question.answers());
          try answers.choose(correct);
               increment question;
          if "other" is in answers;
               answers.choose(other);
               try answers.write();
          elif required==false;
               return false;
          else:
               help.request();
               pause();
               answers.choose(help);
          increment question

     if question.type()==open answer;
          try answers.write(response);
               increment question;
          except question.brainbreak ==true;
               if required==false;
                    return false;
               else:
                    try self.cry();
                    crycount+=1;
                    help.request();
                    pause();
                    answers.write(help);
               increment question

     if question.type()==number rating;
          elif required==false;
               return false;
          else:
               crycount+=random(0,1);
               help.request();
               pause();
               answers.choose(help);
          increment question

self.flop(crycount hours)

Progress! Crying and flopping are significantly reduced. (So is the likelihood of my getting the survey done, but I'm OK with that.) For timing reference, my language utilization report from my year in China was the first time I managed help.request()  for this sort of thing. They, uh, weren't quire sure how to handle that, because these reports aren't the hard part for most people. Their first idea was to ask the residence director to help me. This got the report done, which was some sort of progress, but it involved enough crying (by me) and confusion (by both of us) that she decided to have the program just ... give up. No more language utilization reports for me, it's not worth it. (I agreed. It was really, really not worth it.)

Notice that while someone helping me eliminates the exhaustion cost for a multiple choice or true/false question that is ambiguous or has bad answers, it does nothing about the exhaustion cost for a brain-breaking open ended question, and it reduces but does not eliminate the cost for "rate this from 1-n" type questions. That's part of why the language utilization reports got nixed, and why the survey I was supposed to do for my university after the year abroad was done slowly, painfully, and with help.

And as for things that aren't just teachable skills? Yes, teaching me certain skills (or practice with certain skills that I theoretically have) could have the effect of writing in ways to handle specific exceptions. That's not the same thing as making my exception handling work at a "standard" speed or efficiency, and it's definitely not the same thing as reducing the associated costs for those exceptions.