2 ms·
I do this in my PL/SQL code occasionally, when I'm feeling lazy and either don't want to handle errors properly or want to take advantage of auto-defined iterat
by tbrownaw 13y ago
I do this in my PL/SQL code occasionally, when I'm feeling lazy and either don't want to handle errors properly or want to take advantage of auto-defined iteration variables.
Since it's a nasty dirty hack that tends to misbehave on bad data instead of failing cleanly, I generally restrict it to experimental/throwaway code. Seeing it recommended as a good idea is a bit WTF.
- jlarocco 13y agoI didn't mean to imply it's a good idea or not. In my own code I'd use the null check and throw an exception. It's suspicious that it's trying to update a non-existent record, so I'd usually want it to break so I can fix the underlying logic bug. I was simply pointing out that the technique is available in other languages without using lambda and/or blocks.
- dragonwriter 13y ago> Since it's a nasty dirty hack that tends to misbehave on bad data instead of failing cleanly This assumes that an empty result set of a finder is "bad data"; there are times when this is true (in which case, the basic "teller" idiom as illustrated here isn't a good choice), but there are lots of times where it isn't, too.
- tbrownaw 13y agoThere's also the case where I forget a unique index or get the query wrong, and get several records when I'm only expecting one.
- dragonwriter 13y agoThe teller strategy can work for those; that's all checking that can be done in the teller (or, in the case of teller-implemented-on-top-of-finder) in the finder. There's no reason to repeat the logic checking for this case all over the application.