Timeline for Why should 'boneheaded' exceptions not be caught, especially in server code?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 1, 2021 at 1:52 | history | edited | Paul Draper | CC BY-SA 4.0 | added 1 character in body |
| Jan 1, 2021 at 1:49 | comment | added | Paul Draper | @spectras, the layering you speak of can be as simple as a stack layer; i.e. a function call. There's no more reason to suspect ArrayIndexOutOfBoundsException is corrupting the entire process anymore than a process crashing corrupts the entire OS. (It might have side effects that do that, but that's uncommon.) | |
| Jan 26, 2020 at 11:57 | comment | added | spectras | Now you can sure do that. Games usually do it, using an interpreted language within a vm to segregate user add-ons from game core. But that's a very different topic, and.... It does not involve catching any exceptions. | |
| Jan 26, 2020 at 11:54 | comment | added | spectras | As long as it can guarantee a known state. When it cannot, it crashes like any other well designed software. Even your os does, that's what panics and blue screens are. The flaw in your reasoning is you do not make a difference between layers. A crash on one layer only needs that layer (and all above) reset. This is why the only example you can quote are programs that live at layers boundaries: os, interpreters, VM. A crash in the layer they manage is not a crash in the layer they live in. | |
| Jan 24, 2020 at 19:18 | comment | added | Paul Draper | @spectras, the OS relies on hardware-provided recovery mechanisms, unless of course, it's software emulated. Java code relies on Java virtual machine-provided mechanisms. The capabilities are different, but idea is the same: divide up software and scope your errors. | |
| Jan 24, 2020 at 18:28 | comment | added | spectras | (in fact falling back on that hardware segregation guarantee to prevent contamination is the very reason crashing the application is a good idea - the OS will use its privileged access to hardware to destroy the contaminated context and create a fresh one in a well-known state — if your application could do that, then yes it would be a good idea to do it at application level. And symmetrically, on embedded systems with no such segregation, the typical response to a crash is a reboot, the idea is the same: restore the application to a known state). | |
| Jan 24, 2020 at 18:14 | comment | added | spectras | @PaulDraper in order not to crash on application failure, the OS relies on hardware-enforced segregation to prevent contamination by the unexpected state. Your code has no such thing available. | |
| Jan 24, 2020 at 17:36 | comment | added | Paul Draper | @spectras, you know the program can continue because you know the designed scope of the code. When a process segfaults, your OS does not crash. The OS has no idea how critical that component was, but it knows that it's reasonable to isolate errors to that context. | |
| Jan 8, 2020 at 0:03 | comment | added | spectras | How do ou know the program can sensibly continue? If that's because you carefully evaluated that error source it no longer is a "boneheaded" exception. If it's something you did not plan, then your program is doing something you did not expect, and is now in an unexpected state. There is no telling what invariants no longer hold, what things may be in an inconsistent state and… how long it will corrupt data unnoticed if you leave it be instead of triggering a clean restart by service supervision. | |
| Jan 7, 2020 at 5:52 | comment | added | Paul Draper | @Nat, if other operations are dependent on RemoveBan() then they should not continue. | |
| Jan 6, 2020 at 22:21 | comment | added | Nat | Boneheaded exceptions might cast doubt on the sensibility of continuing. I mean, if someone's getting exceptions from their own code not behaving as intended, it'd seem potentially hazardous to just keep calling that same code anyway in scenarios in which that code could, for example, corrupt a database of user accounts. For example, in the question, they try { RemoveBan(ban); } catch {}, which presumably modifies a database with user accounts; if that throws due to a programming logic error, then what exactly is that code doing, and can it be trusted to keep modifying the database? | |
| Jan 6, 2020 at 22:21 | comment | added | mtraceur | I would say "sensibly do something about it" instead of "sensibly continue" - because there are sensible actions like "log the error, then exit (and probably get restarted by service supervision)" can be called "recovery", it is hardly "continuing", in casual or practical terms, or technical terms within the scope of the process' lifespan. | |
| Jan 6, 2020 at 20:06 | history | edited | Paul Draper | CC BY-SA 4.0 | deleted 16 characters in body |
| Jan 5, 2020 at 2:48 | history | answered | Paul Draper | CC BY-SA 4.0 |