- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
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!
Admin
So is this the answer to the for-case antipattern? The try-case antipattern?
Admin
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.
Admin
I thought bus oriented programming was "the last guy got hit by a bus, and no one knew what he was doing".
Admin
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.
Admin
Confused. Where does it become difficult to debug this?
Admin
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.
Admin
Oh boy, when I read my typing, you can totally see that I am a software developer totally spoiled by syntax checking :-)
Admin
if I had a nickel for every time I've typed the first few characters of a word and pressed <tab> expecting autocomplete ...
I'd be retired, not slinging code.
OTOH, MS Outlook has recently started offering this feature. It ain't half bad. Shame English prose is so much less predictable than C# object models. ;)
Admin
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.)
Admin
No, "puts down" was right. Murdering him with a book on cargo cult programming methods sounds about right.
Admin
But in this case, there's an object $this that is being checked for errors, which are being thrown and caught, and then appropriate actions are made using the same $this object based on those errors. It seems like that should work swimmingly within the context of a php session, especially when you're mostly just looking for an error event to presumably display to the user (think red outlined box), for example, "no billing address." Well, there is a silly part of it, in that you could have more than one error, but this catches only one at a time. That's a major weakness.