• MaxiTB (unregistered)

    Ah, the good old discussion of exceptions not being result states. When you have a situation like this, you are implementing a state machine using exceptions, which is generally a bad practice because exceptions are not here to handle business cases but to signal that a business case failed for technical reasons.

  • RLB (unregistered) in reply to MaxiTB

    Unfortunately, too many languages/libraries still insist on "exceptions are for everything that went wrong" and so make it hard to impossible to distinguish between "this is a bad email address" and "my SMTP server crashed". Looking at you, PHPMailer!

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    So is this the answer to the for-case antipattern? The try-case antipattern?

  • (nodebb) in reply to MaxiTB

    You say that, but what if there are business failures that cannot happen with proper inputs? If somebody tries to send an email to an address which is not a valid email address, would you have return codes for situations like that?

    The article's code definitely doesn't fall under that, though.

  • Andrew (unregistered)

    I thought bus oriented programming was "the last guy got hit by a bus, and no one knew what he was doing".

  • no (unregistered)
    Comment held for moderation.
  • Anne on a Mouse (unregistered) in reply to Andrew

    Best example of that is BeOS’s original graphics layer. Years ahead of its time and lightning fast on hardware which ought to have been mediocre at best (and WAS mediocre at best when run by other OSes). The programmer was a cowboy type but nobody had minded because his stuff actually DID work better than anything anybody else had been able to do. Then he died suddenly and they had to look at his code, and it turned out that not only had he not documented his code very well but he had designed his own programming language which nobody else knew and had no documentation in order to implement his largely undocumented code.

  • Huh? (unregistered)

    Confused. Where does it become difficult to debug this?

  • MaxiTB (unregistered) in reply to Mr. TA

    For inputs you use validation, not exception. You can do this also for email addresses to ensure they are syntactic correct. If you send an email, it's a fire-and-forget action. There is no guarantee that you get an error response or are even able to automatically parse it as such. The only way to ensure the arrival of an email is by directing the user to response (confirmations links are very common). If you try to send a mail to your sever and this fails, it may result in an exception, which obviously needs to be handled appropriately as soon as possible. You don't let is wander up the call stack; you may no longer have the proper context to handle it at this point (for example doing proper retry logic etc). And if the an method cannot send a mail, this is a failure state not an exception, which needs to be handled according to the business case (it's the user after all who has to tell a dev what should happen in this case up front, usually part of acceptance criteria). So yeah, exceptions are generally very low level constructs, the further you get up, the less frequent they become in a good designed software and are often fatal states to abort everything to avoid for example data corruption or undefined unwanted execution branching.

  • MaxiTB (unregistered)

    Oh boy, when I read my typing, you can totally see that I am a software developer totally spoiled by syntax checking :-)

  • WTFGuy (unregistered)
    Comment held for moderation.
  • löchleindeluxe (unregistered) in reply to Huh?

    If you throw away the exception to create an event, you lose the stack trace, amongst other things. (That being said, in the spirit of hope for humans learning and evolving, I hope somebody puts this programmer down with a copy of a book on design patterns. I'm sorry, sits down.)

  • (nodebb) in reply to löchleindeluxe

    I'm sorry, sits down.

    No, "puts down" was right. Murdering him with a book on cargo cult programming methods sounds about right.

  • mastram (unregistered)
    Comment held for moderation.
  • HuH? (unregistered) in reply to löchleindeluxe
    Comment held for moderation.
  • Frank Wilhoit (unregistered)
    Comment held for moderation.
  • eTech Guide (unregistered)
    Comment held for moderation.
  • Rahul Kumar (unregistered)
    Comment held for moderation.
  • xtrenlabs (unregistered)
    Comment held for moderation.

Leave a comment on “Exvention”

Log In or post as a guest

Replying to comment #:

« Return to Article