4 ms·

> passing y=0 the function is clearly a bug. It'd be much better to core dump here. I don't follow, for me it's not clear at all. What if y is user provided? T

> passing y=0 the function is clearly a bug. It'd be much better to core dump here. I don't follow, for me it's not clear at all. What if y is user provided? Then the argument should be checked before calling your function. Then it's checked again inside the function.

stinos 9y ago
What if y is user provided? Then the argument should be checked before calling your function. Well, the bug here is that user input wasn't checked. Then it's checked again inside the function Checking twice is better than never checking at all (i.e. in the case argument validation didn't happen outside of the functiion)
- leni536 9y ago
  > Well, the bug here is that user input wasn't checked. It will just result in your minefield function being wrapped inside safe variant which just returns an error in some form. Which could happen in the first place. Seriously the best thing is throwing an exception on the bug path too. If it's truly a bug, then it shouldn't be handled and you get what you just described. If it's a bug that could be constrained into a subsystem, you can maybe get away buy bringing down the subsystem only. That's what actually happens with your strategy too, but on the process/OS/service hypervisor level.
  - AstralStorm 9y ago
    In that case, a top level catch statement should grab it. And if not, you can install an uncaught exception handler.
  - ensiferum 9y ago
    "Seriously the best thing is throwing an exception on the bug path too. If it's truly a bug, then it shouldn't be handled and you get what you just described." Except that you don't get a call stack (and process state), which is like the best feature of a core dump. Just open it in your debugger and you're immediately looking at a whole lot of more of information about what happened than what an exception can tell you.

4 ms·

> passing y=0 the function is clearly a bug. It'd be much better to core dump here. I don't follow, for me it's not clear at all. What if y is user provided? T

by leni536 9y ago

stinos 9y ago
What if y is user provided? Then the argument should be checked before calling your function. Well, the bug here is that user input wasn't checked. Then it's checked again inside the function Checking twice is better than never checking at all (i.e. in the case argument validation didn't happen outside of the functiion)
- leni536 9y ago
  > Well, the bug here is that user input wasn't checked. It will just result in your minefield function being wrapped inside safe variant which just returns an error in some form. Which could happen in the first place. Seriously the best thing is throwing an exception on the bug path too. If it's truly a bug, then it shouldn't be handled and you get what you just described. If it's a bug that could be constrained into a subsystem, you can maybe get away buy bringing down the subsystem only. That's what actually happens with your strategy too, but on the process/OS/service hypervisor level.
  - AstralStorm 9y ago
    In that case, a top level catch statement should grab it. And if not, you can install an uncaught exception handler.
  - ensiferum 9y ago
    "Seriously the best thing is throwing an exception on the bug path too. If it's truly a bug, then it shouldn't be handled and you get what you just described." Except that you don't get a call stack (and process state), which is like the best feature of a core dump. Just open it in your debugger and you're immediately looking at a whole lot of more of information about what happened than what an exception can tell you.