When I request segment fully or partially outside the input text parameter instead of returning existing part (or empty) it raises uncatch'able error. It is so different than any language I know that I consider it bug or at least improvement candidate.
Rationale:
It can be cheaply imemented in library once (dry)
It requires lot of ugly and old-fashioned if-thens on every use instance in every app from every developer made further complicated by modest text function set (anti-dry)
It is not logical as 2-element subset of empty set is a perfectly valid empty set and most (all?) other languages to it that way
E.g.: fragment ("key",2,5) = "ey", fragment ("key",5,5)="", fragment ("",1,5)="".
@ewpatton do you think there is a chance for a fix ?
I can but it means me and everybody writing her/his workarounds (ANTI-DRY) around platform implementation.
This is why I've brought it here plus I believe AI2 and it's Community are so great already.
I also understand and accept that it can be at the bottom of AI2 needs/backlog.
Let me wish all of you Merry Xmass and a happy New Year and that AI2 becomes even better.
The Java String.substring method does throw an IndexOutOfBoundsException when the indices are not within the string's bounds, so I would argue this is expected behavior.
@ABG
screen's on error does not catch it.
Could u share downsides...? @ewpatton yes but in java I can catch it while on screen error does not catch it.
Plus AFAIK general catch all method is not recommended (there should be local catch's to clearly bind error handling to particular code and not share it for whole app/screen)
B rgds
IMHO, One of the lessons it should teach is defensive programming.
If the coder does not anticipate and code for an error, it should hurt at run time, in one way or another, hopefully locally to where the injury occurs and as soon as possible after the injury occurs.
Admittedly, the error reporting is not always adequate.
Covering up an error is not always a good idea.
If I order something online, and it turns out to be out of stock,
how happy would I be to receive an empty box?
Something goes wrong out of blue sky - best is to have local catch exception (logic encapsulation in same procedure/function/method) targeted at specific exceptions 1st (like @ewpatton mentioned)
Error in input data. I prefer strict checking whenever possible using e.g. regexp or if-then or exceptions depending on language/environment/how strict is grammar of input. This means you DO WANT to check.
Completely perfect business case when you want to get from given element to end of string and it does not matter what you get - my case fragment("AAA", 3,999). It could return whatever left and if I care I'd check it (this is what I like most).
If the implementation throws locally catcheable exception that is fine too (as @ewpatton described) especially as catch approach produces concise code with clear distinction of unexpected cases and their handling.
But the AI2 implementation lacks local catching and screen-level ctach (On Error event) does NOT catch many exceptions.
I don't believe catching all the errors from whole screen without access to data in question (probably scoped locally to method body) is the pedagogically right or even convenient but it does not work either.
So I believe within current AI2 concept One can:
leave as it is and expect programmer to build their own string methods (rapid etc...) - cheapest and fastest
adding catch branch to procedures, functions and possibly other scopinig components (local variable definitions as these can handle ifs and loops) and exposing exception type/number/enum - BEST IMHO
making text and list objects return perfectly fine empty-or-whatever-left substrings and list members (for list members mimic dictionary behaviour) - 2nd CHEAPEST and easiest to use IMHO
Thanks for interesting conversation and best regards & Merry XMass & a happy New Year
