Timeline for Avoiding throw because we are not sure the exceptions will always be caught
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 20, 2024 at 21:03 | comment | added | Ángel | I wouldn't assume your company is doing this just because this is a huge codebase, @sayanel, unless there are more things in line to make this other approach robust as well. | |
| Apr 20, 2024 at 19:36 | comment | added | Cort Ammon | @sayanel When exceptions were invented, they were trying to make things easier, but probably overshot the mark a bit. For lots of software, where high reliability is desirable but not required, they're quite effective. Several languages have explored ways to make things more provable (such as requiring you to explicitly list what exception classes you might throw), but we're still working on it as an industry. | |
| Apr 20, 2024 at 7:18 | comment | added | sayanel | It's a very interesting read, thank you. And unlike most responses, it explain why my company has this rule. We are indeed closer to the million lines of code, and from your post I understand that this "pattern" (boolean return, init method...) is safer and less error prone. But I am a bit surprised that the more "modern" approach (exceptions) isn't safer/better/easier at large scale (I know newer isn't always better, but I have the feeling that in software, newer means simplifying dev work) | |
| Apr 19, 2024 at 19:30 | history | edited | Cort Ammon | CC BY-SA 4.0 | added 52 characters in body |
| Apr 19, 2024 at 19:20 | history | answered | Cort Ammon | CC BY-SA 4.0 |