3 ms·

The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_. His definition depends on

The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_. His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exception resulting it its failure. In the context of Design by Contract, the list of things that can cause an exception include: * hardware/OS errors * calling a method on a null reference * calling a method that itself fails * discovering a pre-condition isn't true * discovering that a post-condition isn't true * discovering that a class-invariant isn't true * loop invariant failure or lack of progress * assertion failures * explicit triggering of an exception I highly recommend Object Oriented Software Construction.

jstimpfle 8y ago
I think this is a hair-splitting distinction and it does not work reliably. Sorry. Things that truly "cannot" happen => you do not know how to recover => you terminate the program. That's it.
- gwright 8y ago
  That is why the definition is recursive. If every failure triggers a new exception all the way up the call stack, then your program fails.
  - jstimpfle 8y ago
    Yeah, so what was the point to begin with?
    - gwright 8y ago
      Do you understand Design By Contract? That is the theory that provides the distinction between a function/method finishing with success or with failure. The notion of contract is what distinguishes an exception from a glorified GOTO.
      - gwright 8y ago
        In re-reading, my response comes across as much more flippant than I intended. I was just trying to re-emphasize that the definition of an exception is an integral component of Meyer's design by contract methodology and not a stand alone concept.
gnoack 8y ago
I've written an article on error handling some point and ended up with: "An error is when the program is operating outside the intended path of execution." What counts as intended is a question of definition, but in concrete examples of local reasoning within a function this question is usually easier to answer. Thinking about it in terms of (explicit or implicit) contracts, like Bertrand Meyer, sounds like a smart idea. https://blog.gnoack.org/post/error_handling/ https://blog.gnoack.org/post/error_handling/
- jstimpfle 8y ago
  > Warning: Textual logging is not an error handling strategy. Logs are not meant for machine consumption so it’s hard to have automated monitoring based on them. I'd beg to disagree. As for the general statement of your post, I like how you're talking about stakeholders and (specification) bounds but I don't think it's an actionable viewpoint. The idea of "Bubbling up errors" inside a program is caught in the software reuse mindset but it's not possible to take action on encountering a true error (here "true" means "outside specifiation"). That's because the state of your whole program is undefined after the encounter. Which means that the best you can do is to call abort() and hope that the program will end with some info for debugging. (Unless we are talking about a VM or sandboxed code, in which case again you could just call some equivalent of abort() from the code inside and "catch" that in the host code and restart the VM or something).
  - gbear605 8y ago
    In Java, your true error dichotomy is done using checked versus unchecked exceptions. Checked exceptions can usually be handled while unchecked exceptions usually can’t be, so they aren’t usually caught and instead just bubble all the way up.
  - gnoack 8y ago
    Thanks for the feedback. :) To clarify, in the context of the article, "making errors observable from the outside" is not meant at the per-function level, but meant at the level of the whole program, which includes abort(). I should improve the wording there. abort() is perfectly legitimate if you can't recover within the same process. It's not at odds with routing to the right stakeholder, as long as the parent process catches the crash and does appropriate error handling (e.g. "Send a crash report" dialogs or other watchdogs). Regarding textual logging, I'm not sure exactly which part you disagree with. :) I'm aware that people commonly write regex-based extractors, and I've done the same, but having the choice I'd always go for a more schema-ful error reporting channel. That's more lightweight both for reading and for writing it, and avoids a whole class of regex bugs.
vram22 8y ago
>I highly recommend Object Oriented Software Construction. I do, too. I had read most of the book [1] some years ago. It is really good. But readers should know that they need to be ready to put in enough time to read, understand and digest it, not just because it is a thick book, although it is that, but because, true to Bertrand Meyer's style, it is detailed, systematic, thorough, etc. It's not one of those books where you can read it in a few days and then start applying its stuff to your work, nor is it for casual programmers who are only into the field to make some quick bucks. [1] https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction https://en.wikipedia.org/wiki/Object-Oriented_Software_Const... BTW, the book may have an Easter egg in it.

jstimpfle 8y ago

I think this is a hair-splitting distinction and it does not work reliably. Sorry. Things that truly "cannot" happen => you do not know how to recover => you terminate the program. That's it.

gwright 8y ago
That is why the definition is recursive. If every failure triggers a new exception all the way up the call stack, then your program fails.
- jstimpfle 8y ago
  Yeah, so what was the point to begin with?
  - gwright 8y ago
    Do you understand Design By Contract? That is the theory that provides the distinction between a function/method finishing with success or with failure. The notion of contract is what distinguishes an exception from a glorified GOTO.
    - gwright 8y ago
      In re-reading, my response comes across as much more flippant than I intended. I was just trying to re-emphasize that the definition of an exception is an integral component of Meyer's design by contract methodology and not a stand alone concept.

gnoack 8y ago

I've written an article on error handling some point and ended up with: "An error is when the program is operating outside the intended path of execution." What counts as intended is a question of definition, but in concrete examples of local reasoning within a function this question is usually easier to answer. Thinking about it in terms of (explicit or implicit) contracts, like Bertrand Meyer, sounds like a smart idea. https://blog.gnoack.org/post/error_handling/ https://blog.gnoack.org/post/error_handling/

jstimpfle 8y ago
> Warning: Textual logging is not an error handling strategy. Logs are not meant for machine consumption so it’s hard to have automated monitoring based on them. I'd beg to disagree. As for the general statement of your post, I like how you're talking about stakeholders and (specification) bounds but I don't think it's an actionable viewpoint. The idea of "Bubbling up errors" inside a program is caught in the software reuse mindset but it's not possible to take action on encountering a true error (here "true" means "outside specifiation"). That's because the state of your whole program is undefined after the encounter. Which means that the best you can do is to call abort() and hope that the program will end with some info for debugging. (Unless we are talking about a VM or sandboxed code, in which case again you could just call some equivalent of abort() from the code inside and "catch" that in the host code and restart the VM or something).
- gbear605 8y ago
  In Java, your true error dichotomy is done using checked versus unchecked exceptions. Checked exceptions can usually be handled while unchecked exceptions usually can’t be, so they aren’t usually caught and instead just bubble all the way up.
- gnoack 8y ago
  Thanks for the feedback. :) To clarify, in the context of the article, "making errors observable from the outside" is not meant at the per-function level, but meant at the level of the whole program, which includes abort(). I should improve the wording there. abort() is perfectly legitimate if you can't recover within the same process. It's not at odds with routing to the right stakeholder, as long as the parent process catches the crash and does appropriate error handling (e.g. "Send a crash report" dialogs or other watchdogs). Regarding textual logging, I'm not sure exactly which part you disagree with. :) I'm aware that people commonly write regex-based extractors, and I've done the same, but having the choice I'd always go for a more schema-ful error reporting channel. That's more lightweight both for reading and for writing it, and avoids a whole class of regex bugs.

vram22 8y ago

>I highly recommend Object Oriented Software Construction. I do, too. I had read most of the book [1] some years ago. It is really good. But readers should know that they need to be ready to put in enough time to read, understand and digest it, not just because it is a thick book, although it is that, but because, true to Bertrand Meyer's style, it is detailed, systematic, thorough, etc. It's not one of those books where you can read it in a few days and then start applying its stuff to your work, nor is it for casual programmers who are only into the field to make some quick bucks. [1] https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction https://en.wikipedia.org/wiki/Object-Oriented_Software_Const... BTW, the book may have an Easter egg in it.