Postfix if with else

Today I found myself writing

   do A if possible, else do B if possible, else error

English that is.

But it caused me to think about Perl's Postfix if

     statement if condition;
  versus
     if( condition ) {code} [[elsif(cond) {code}]* else {code}]
  i.e.

     if( condition ) {code}
     if( condition ) {code} else {code}
     if( condition ) {code} elsif(cond) {code} else {code}
   etc.

Strange to many programming languages, but sometimes makes conde more readable.

I wonder if the posifix if woth else, that I wrote in English, might be worth thinking about.

Syntactically  it is a ternary operator:
      operand1  IF operand2 ELSE operand3

I vaguely recall disjoint operator and function syntax - Algol 68? or was it Algol 60? - ...

Reading email in more than place

Andy Glew

1:55 PM  -  Public

I read email in more than one place, on more than one device, in more than one situation (phone (actually, PDA, but that's a story in itself), tablet, tablet PC by itself, tablet PC docked with 4 big monitors).

I need more dispositions than Archive or Delete.

I need "I can't read this now/here/on this device".

I suppose that it might be useful to be able to say where I could read it - e.g. "defer reading until I'm docked at my desk with 4 external monitors".

But "I can't read read it {in this situation}" is a simple button. It could probably fit on my phone's screen.  Whereas "Defer to another situation" is a multi-valued control, and harder to fit.

Note that "I can't read it in this situation" is NOT the same as "Later".  It may be a superset.  But being re-presented an email to read, later, on the same device that it was too painful to read on in the first place doesn't help.

--

Possibility of learning: record where deferred, and where finally read. Infer. Next time the user presses the "I can't read this {in this situation}" button, you might prompt "Read it at home?"

--

As usual, if already available, I'd like to hear about it.

Error Handling

I sometimes say "the most important part of programming is error handling".

This is not true. Shown by how many programs, how many library routines, how much code, does not handle errors at all.  Successful programs, libraries, code.

How about "one of the hardest parts of programming is error handling"?  That error handling is hard is one of reasons it is so often neglected.

And "one of the biggest barriers to reuse is error handling".

In at least two senses:

(1) You pick up a tool or library, try to use it on what you believe to be correct input - and it craps out with something like a Python stack dump.  Rather than debug, you try something else. Whereas, if an error message had explained what the problem was - if the code had checked format, rather than assuming - then you might have fixed the input.

(2) In a much narrower sense, the error handling conventions a code assumes may get in the way.  E.g. I assume that you throw an exception, you assume that it returns 0. Or -1.  If throwing an exception, what type of exception object do I throw?  (I have given up, and just throw strings.)


Can you tell I am debugging Python today?  I'm not 100% sure, but the Python code I have encountered has made more such assumptions...