4 ms·

> It is almost never okay for a library to abort the process. For a library with a design principle to be as hard to misuse as possible it seems like the right

> It is almost never okay for a library to abort the process. For a library with a design principle to be as hard to misuse as possible it seems like the right decision, and the "exception to the rule". Infinitely better to crash than to potentially let the process/library run in some kind of degraded state. If you are aware of this behaviour and are savvy/experiences enough you'll either 1) Catch the panic and perform an appropriate library 2) Use a different library.

IshKebab 8y ago
> Infinitely better to crash than to potentially let the process/library run in some kind of degraded state. Why? Just set the entire library to "failed" mode and have every function return an error or do nothing from that point forward. That is far more sensible than just panicking and bringing down the entire application. Imagine if people want to use this in a cash machine or something like that.
- heavenlyblue 8y ago
  I would much rather the cash machine crashes than starts communicating with the bank seeded by 00*inf bytes of random. Besides, what exactly do you expect to do with the library in an "exceptional condition"? Do I now need to check the output of every single function for some non-local effects they have on each other?
  - blub 8y ago
    How can the library know that the cash machine will communicate with the bank, or that there even is a cash machine? The library should just tell the program that it failed go perform its task, not guess at what its parent program could, should or would do. Note that the discussion started from "abort". Maybe the authors meant something else by abort, but in a system programming context it means calling abort and terminating the program's execution immediately. If they just meant it as a synonym for panic, we're just having a nice discussion here.
blub 8y ago
The issue is that the library can't know what state the program is running in, since it's a library... it has a job to perform some crypto functionality and it can only either return a result or an error for that particular operation. When libraries start calling abort out of the blue it's like the janitor deciding to send everyone home for the day because their mop broke. It's not their call to make :) Panicking or any other error handling mechanism which permits the main application to decide how to continue is perfectly fine.
- adwn 8y ago
  > When libraries start calling abort out of the blue it's like the janitor deciding to send everyone home for the day because their mop broke. A more apt analogy would be the janitor that pulls the fire alarm because they saw smoke coming out of the boiler room. So yes, it's their call to make, and it would be the right call. Besides, as lifthrasiir points out, you can isolate this behavior in Rust, akin to triggering the fire alarm for a single building, but not for the entire complex.

IshKebab 8y ago

> Infinitely better to crash than to potentially let the process/library run in some kind of degraded state. Why? Just set the entire library to "failed" mode and have every function return an error or do nothing from that point forward. That is far more sensible than just panicking and bringing down the entire application. Imagine if people want to use this in a cash machine or something like that.

heavenlyblue 8y ago
I would much rather the cash machine crashes than starts communicating with the bank seeded by 00*inf bytes of random. Besides, what exactly do you expect to do with the library in an "exceptional condition"? Do I now need to check the output of every single function for some non-local effects they have on each other?
- blub 8y ago
  How can the library know that the cash machine will communicate with the bank, or that there even is a cash machine? The library should just tell the program that it failed go perform its task, not guess at what its parent program could, should or would do. Note that the discussion started from "abort". Maybe the authors meant something else by abort, but in a system programming context it means calling abort and terminating the program's execution immediately. If they just meant it as a synonym for panic, we're just having a nice discussion here.

blub 8y ago

The issue is that the library can't know what state the program is running in, since it's a library... it has a job to perform some crypto functionality and it can only either return a result or an error for that particular operation. When libraries start calling abort out of the blue it's like the janitor deciding to send everyone home for the day because their mop broke. It's not their call to make :) Panicking or any other error handling mechanism which permits the main application to decide how to continue is perfectly fine.

adwn 8y ago
> When libraries start calling abort out of the blue it's like the janitor deciding to send everyone home for the day because their mop broke. A more apt analogy would be the janitor that pulls the fire alarm because they saw smoke coming out of the boiler room. So yes, it's their call to make, and it would be the right call. Besides, as lifthrasiir points out, you can isolate this behavior in Rust, akin to triggering the fire alarm for a single building, but not for the entire complex.