It's good until you want to customize it a lot.
I guess I've always customized them a lot, because it's so helpful IMO. e.g. zero padding counts and ISO8601 formatting dates, so lexical sorting works.
Backtick itself isn't hard to type. It's one keystroke on my keyboard
@greggirwin if
`"..."` is so utterly bad for you, let's consider just an empty issue # "...", because #` is completely ugly and using only opening quote makes no sense to me, if it's quotes they should be on both ends. # "..." is somewhat similar to char syntax though. But then any other symbol allowed in issues will be better than backquote. ## #! #$ #% #= #| #/ #\ #. #~
A poll from Nenad ☻
Which way to you guys use try most of the time?
- To silence errors, as in
if error? try [...] [..after-error recovery..] - To catch errors and process them later, as in
set/any 'err try [...] (... later err is processed...) - I never used
try
Please post your answers into thread if possible. Thanks.
18 replies
Instead of try / catch, how about... what amounts to enums... custom types that only accept a few things - either succeeds or the error message comes directly from the type
Note that in Red
try/catch isn't a thing. We have throw/catch which is not specifically error related, but is about general non-local flow control.
Yes, but when I think of try, catch is always trying to sneak into to the party
Into
I dont know much about Java. I could never bring myself to use it.
You handle each one in a custom type that ideally models your application - for error messages, There's a separate type for recovery.
@kskarthik:poddery.com that certainly would be :-) Current Red’s IO is pretty limited, you can do requests and not serve anything, however, there’s IO branch with the new IO which can do both and you can write a HTTP server with it. I am working on one and I believe there will be some simpler variant in the standard library (basic HTTP/1.0 server can be done in few lines).
it’s not much, I know :-)
@kskarthik:poddery.com Thanks! My current focus is not content, but strong server security by default where it does not stand very bad
Looks like we've got trojans uploaded to our wiki. I reverted it and reported it using GH form, for now.
@hiiamboris: github wiki's are editable by anyone. Better to move wiki to version control
Do we have a function that creates a contex and binds the following code to context it running?
I want to create a with function:
with [a: 33 c: 33] [...code...]Which is equivalent to:
do bind [...code...] make object! [a: 33 c: 33]But I would like to know if it already exists.
Feedback is welcome, as there are many variants out there and it's likely something we will make standard.
Oh my God, I have deleted everything instead of editing it! :-(
Here I am again:
Why not allowing path in parse SET? It would make setting values in context very easy: (Please pardon me the wrong usage of IFbut I have still not studied it)
valid?: func [data test-name] [
result: switch test-name [
size [either data ... [true] [false]]
position [either data ... [true] [false]]
]
]
options: [size 00x200 position above]
ctx: make object! [
size: none
position: none
]
parse options [
set ctx/size 'size pair! (if not valid? ctx/size 'size] [fail!]
set ctx/position 'position word! (if not valid? ctx/position 'position] [fail!]
]
Note:
options: [size 300x200 position above]
But Gitter removes the number
3 for no reason!
@dockimbel noted red/red#3528 that path's higher overhead is a primary reason they aren't supported. However, if you don't use paths and aren't penalized, I don't see why those who want to use them shouldn't be allowed to. As long as they don't complain about performance. If there's no wish ticket for that, feel free to open one.
@GiuseppeChillemi You can bind the rule to
ctx. E.g. working example:between?: func [data min-test max-test][
all [min-test <= data max-test >= data]
]
valid?: func [data test-name] [
switch test-name [
size [all [between? data/x 250 500 between? data/y 200 400]]
position [find [above below left right] data]
]
]
ctx: make object! [size: none position: none]
options: [size 300x200 position above]
parse options bind [
'size set size pair! if (valid? size 'size)
'position set position word! if (valid? position 'position)
] ctx
== true
ctx
== make object! [
size: 300x200
position: 'above
]
*in case of longer parse rules and code in parens
Don't forget you can write
parse options [set ctx/size ..] as parse options reshape [set !(in ctx 'size) ..]. See reshape
You get precisely bound words this way.
You pay a little cost of preparing your rule block, but you don't pay extra during parsing.
@toomasv I simply mean:
struct: [size "aaa" position "bbb" color [background none text none]]
options: [size 300x200 position above background red]
parse options [
'size set struct/size pair! if (valid? struct/size 'size)
'position set struct/position word! if (valid? struct/position 'position)
'backgound-color set blk/color/background word! if (valid? blk/color/backgropund 'colors)
]