5 ms·

> caching the result of a repeated function call is no longer necessarily safe Not seeing this one. Unpredictable exception-throwing only happens if the work b

by mrec 10y ago

> caching the result of a repeated function call is no longer necessarily safe Not seeing this one. Unpredictable exception-throwing only happens if the work being done by your function isn't pure, i.e. it depends on something other than the function parameters. And if that's the case then caching its result is a bad idea anyway. What am I missing here?

lmm 10y ago
If you make an exception-aware cache that part will behave correctly. The problem is that you can't just move the call around, store the value and use it later, because you're changing where the evaluation happens, so that can lead to an exception happening earlier or later and changing which functions get evaluated. "Everyone knows" you shouldn't use exceptions as control flow, but it's very easy to not realise you were doing it by accident (I once came across a method that always exceptioned and never did what it looked like it was meant to) until you refactor and break something.
acomar 10y ago
> Unpredictable exception-throwing only happens if the work being done by your function isn't pure, i.e. it depends on something other than the function parameters. This isn't true. The canonical example is trying to grab the first element of an empty list. You either check and catch the error or eat the exceptional behavior, but some pure functions are just partial and aren't defined for all inputs. (Whether or not they throw a catch-able exception depends on language/implementation and is really not relevant to my point.)
- gpderetta 10y ago
  How's that unpredictable? It will always throw for all and only empty lis arguments.
  - acomar 10y ago
    It's unpredictable in the sense that even with a compile-time check that the function I'm calling is pure, I don't have any guarantee that it won't throw on my particular inputs. This comes up a lot in the Haskell community -- code outside IO is guaranteed by the compiler to be pure, but you can still get hit with an asynchronous exception because you called a partial function.

by mrec 10y ago

lmm 10y ago

If you make an exception-aware cache that part will behave correctly. The problem is that you can't just move the call around, store the value and use it later, because you're changing where the evaluation happens, so that can lead to an exception happening earlier or later and changing which functions get evaluated. "Everyone knows" you shouldn't use exceptions as control flow, but it's very easy to not realise you were doing it by accident (I once came across a method that always exceptioned and never did what it looked like it was meant to) until you refactor and break something.

acomar 10y ago

> Unpredictable exception-throwing only happens if the work being done by your function isn't pure, i.e. it depends on something other than the function parameters. This isn't true. The canonical example is trying to grab the first element of an empty list. You either check and catch the error or eat the exceptional behavior, but some pure functions are just partial and aren't defined for all inputs. (Whether or not they throw a catch-able exception depends on language/implementation and is really not relevant to my point.)

gpderetta 10y ago
How's that unpredictable? It will always throw for all and only empty lis arguments.
- acomar 10y ago
  It's unpredictable in the sense that even with a compile-time check that the function I'm calling is pure, I don't have any guarantee that it won't throw on my particular inputs. This comes up a lot in the Haskell community -- code outside IO is guaranteed by the compiler to be pure, but you can still get hit with an asynchronous exception because you called a partial function.