Ned Batchelder @nedbat on why exceptions are better than returning status codes.
Uncategorized
4
Posts
3
Posters
0
Views
-
Ned Batchelder @nedbat on why exceptions are better than returning status codes.
Exceptions let you leave error handling code out of much of your code. Exceptions are transmitted automatically through layers that have no knowledge of them, so you can write useful code that has no error handling logic at all.
-
Ned Batchelder @nedbat on why exceptions are better than returning status codes.
Exceptions let you leave error handling code out of much of your code. Exceptions are transmitted automatically through layers that have no knowledge of them, so you can write useful code that has no error handling logic at all.
-
Ned Batchelder @nedbat on why exceptions are better than returning status codes.
Exceptions let you leave error handling code out of much of your code. Exceptions are transmitted automatically through layers that have no knowledge of them, so you can write useful code that has no error handling logic at all.
@amoroso @nedbat Exceptions are three GOTOs in a trenchcoat. :)
Seriously though, it wasn't until reading Object Oriented Software Construction by Bertrand Meyer that I became comfortable with exceptions. This the book that introduces the Eiffel language and Design by Contract (DbC). It's a great book - clear and insightful, engaging and readable for a textbook - very highly recommended.
Meyer's position was that you clearly define the scope of responsibility of a routine as well as its requirements and expectations. Exceptions are for exceptional conditions _only_ - issues where the routine's contract with its caller is broken. DbC makes you think more clearly and intentionally when you create a routine; part of that is clearly documenting which exceptions a routine can throw. One of my biggest complaints about OO systems is that there's no way to get a complete list of exceptions that could be emitted from a function call so you can effectively handle them; I'm not sure that's even possible. Either way it makes the code difficult to reason about. Not that status codes are any better in practice - the tradeoff seems to be between clear implementation code and routines with clearly documented behavior.
As noted in the post, some languages don't have exceptions; here's an exploration into error handling in Modern Fortran that tries to do better than just returning an integer https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-1-exploration/
-
@amoroso @nedbat Exceptions are three GOTOs in a trenchcoat. :)
Seriously though, it wasn't until reading Object Oriented Software Construction by Bertrand Meyer that I became comfortable with exceptions. This the book that introduces the Eiffel language and Design by Contract (DbC). It's a great book - clear and insightful, engaging and readable for a textbook - very highly recommended.
Meyer's position was that you clearly define the scope of responsibility of a routine as well as its requirements and expectations. Exceptions are for exceptional conditions _only_ - issues where the routine's contract with its caller is broken. DbC makes you think more clearly and intentionally when you create a routine; part of that is clearly documenting which exceptions a routine can throw. One of my biggest complaints about OO systems is that there's no way to get a complete list of exceptions that could be emitted from a function call so you can effectively handle them; I'm not sure that's even possible. Either way it makes the code difficult to reason about. Not that status codes are any better in practice - the tradeoff seems to be between clear implementation code and routines with clearly documented behavior.
As noted in the post, some languages don't have exceptions; here's an exploration into error handling in Modern Fortran that tries to do better than just returning an integer https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-1-exploration/
@arclight Thanks for the insight.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
a tutta la mia rete... ho portato nel fediverso la mia amata amica @TeresaPotenza
Giornalista indipendente, speciale nel fare le inchieste, podcaster, esperta di strumenti di miglioramento personale e professionale (con e senza AI).
Ha qualche difficoltà con il fediverso e la sua organizzazione perché sta muovendo i primi passi, per ora è su mastodon.uno
Aiutatemi ad aiutarla e a farla sentire benvenuta vi prego! ❤️
Chiamo un #mastoaiuto così impara pure a usare gli hastag
-
@luca No. Lo ho riordinato e va in mona tuti quanti.
-
@arclight Thanks for the insight.
-
Giving #Sharkey one more try (the 9th for the record).
Yes I can be pretty persistent, LOL 😅
Send me pictures of your cute pets in case it doesn't work... 🙃
#SharkeyMonAmour #MySoCalledSudoLife
-
@DigiDavidex
Si, frequentemente.
-
Attenzione, sciopero! ✈️
Viaggiatori, si prevedono agitazioni sindacali il giorno 29/10 in diversi scali italiani.
Nel link qui sotto trovate i dettagli.
Indovinate chi dovrebbe partire proprio il 29?
Vi farò sapere come va a finire.
https://www.theflightclub.it/2025/10/sciopero-29ottobre-malpensa-linate-airfrance/
@Viaggi #sciopero #aereo #viaggio #viaggiare #trasporti #scioperotrasporti #sfiga
-
@amoroso @nedbat Exceptions are three GOTOs in a trenchcoat. :)
Seriously though, it wasn't until reading Object Oriented Software Construction by Bertrand Meyer that I became comfortable with exceptions. This the book that introduces the Eiffel language and Design by Contract (DbC). It's a great book - clear and insightful, engaging and readable for a textbook - very highly recommended.
Meyer's position was that you clearly define the scope of responsibility of a routine as well as its requirements and expectations. Exceptions are for exceptional conditions _only_ - issues where the routine's contract with its caller is broken. DbC makes you think more clearly and intentionally when you create a routine; part of that is clearly documenting which exceptions a routine can throw. One of my biggest complaints about OO systems is that there's no way to get a complete list of exceptions that could be emitted from a function call so you can effectively handle them; I'm not sure that's even possible. Either way it makes the code difficult to reason about. Not that status codes are any better in practice - the tradeoff seems to be between clear implementation code and routines with clearly documented behavior.
As noted in the post, some languages don't have exceptions; here's an exploration into error handling in Modern Fortran that tries to do better than just returning an integer https://matthiasnoback.nl/2025/07/fortran-errors-and-error-handling-part-1-exploration/
-
Microsoft Teams farà la spia al tuo capo quando non sei in ufficio! A dicembre il deploy del tracciamento della posizione
📌 Link all'articolo : https://www.redhotcyber.com/post/microsoft-teams-fara-la-spia-al-tuo-capo-quando-non-sei-in-ufficio-a-dicembre-il-deploy-del-tracciamento-della-posizione/
#redhotcyber #hacking #cti #ai #online #it #cybercrime #cybersecurity #technology #news #cyberthreatintelligence #innovation #privacy
