trying to play a game of throw and catch

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Weirdan wrote:
This is a bad idea, partly because the exception-handling system is significantly less efficient than normal program execution; exceptions are a rare event, so the normal program shouldn’t pay for them. Also, exceptions from anything other than error conditions are quite confusing to the user of your class or function
This is an opinion mostly, even if of an expert. Except performance issues which are (were?) specific to implementation of exceptions in C++. And this opinion was expressed 5 years ago.
Yea I realize that, but the expert opinion of others are often used in this forum so I figured I'd join the party. :P

Although exceptions (I assume) are just plain objects in PHP...there is still more overhead than using a return, no dought. However, it is not even the performance issues I am concerned with...it's the over use of exceptions...maybe not even in throwing but in catching and handling...

When it's suggested they are a form of "alternative conditional syntax"...I don't think that practice is as language centric as the implementation details exceptions in C++ versus PHP. Like Bruce says, if you go into the a situation trying to pound everything with your new hammer, you'll quickly get into trouble...I don't think he was pertaining strictly to performance.

Believe it or not, there are indeed situations where codes make for a more elegant solution. Why else would the PHP exception have a getCode()? :P

After some reflection, I had a slight change of heart in and accepted a more liberal use of try-catch (I certainly like the idea of a more explicit method of error handling). But I still don't see them as a new alternative to conditionals...that kind of thinking will lead you down the path of most resistance, much like noobs expercience when they go bonkers with inheritence or even worse MI. It's a tool, use it by all means, but when you start suggesting replacement or alternative...I'm not so sure I agree 100%.

IMHO it's best to start small with a defined set of rules and build from that. After all, they are called exceptions and not expectations which is the difference I made explicit so as to make the introduction for scoattayy a little easier. If he starts using them as alternative conditionals...without a reason to justify...that would likely lead to something similar to spaghetti code circa GOTO statements. .

Cheers :)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Chris Corbyn wrote:If all you want to use Exceptions for is fatal errors then yes the whole "exceptional situation" game comes into play, but when you're using them as a conditional language construct you can be far looser with where you apply them. In plain english all you're saying is "I'd like to do this, but I can't I need to do this".
I should probably start posting what my definitions are before posting explanations.. because that is exactly what I would call an exceptional circumstance - "I should be able to do this, but I can't - Exception!" The object throwing wouldn't have the responsibility or knowledge of what to do in the exception circumstance, so it must raise it to it's superior so that the superior can decide what to do.

I didn't explain my use of catch, only throw, catching and handling is an everyday part of programming, imo, for example, you might try to retrieve an index from an array that does not exist. You could either if (isset($array[$index]) { or try it, catch the exception, then proceed (In PHP this is not a likely scenario.. but in Java, for example, it's more common.)

Code: Select all

try {
  someVar = array.at(i);
} catch (IndexOutOfBoundsException e) {
  // index does not exist.. perhaps set someVar to a default value
}
So instead of the Array object deciding what value is default, the superior object can decide..
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Weirdan wrote:
This is a bad idea, partly because the exception-handling system is significantly less efficient than normal program execution; exceptions are a rare event, so the normal program shouldn’t pay for them. Also, exceptions from anything other than error conditions are quite confusing to the user of your class or function
This is an opinion mostly, even if of an expert. Except performance issues which are (were?) specific to implementation of exceptions in C++. And this opinion was expressed 5 years ago.
Not to mention the exception procedure is only incurred if the exception occurs*.. compared to the other if () condition, which will always be incurred.


*Bit of a tongue twister.. sorry.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:I'm serious, show me in practical fashion, how exceptions (constructs, practices, etc) could be used to replace conditionals and actually result in cleaner, more loosely coupled code or whatever the benefits you see. Do it subjectively, not just giving me a one track mind and if your arguments are valid, you'll convince me and I'll start employing exceptions more frequently (obviously not as a complete replacement). This afterall, was the whole reason for the disscussion. scottayy wanted to see some practical examples...
You quoted everything I said except that which related to your question:
arborint wrote:The fact that try/catch bubbles the "return value" up for you automatically is one interesting/handy part of this alternate conditional syntax. That means intermediate code does not needs to know how to handle passing back the return value. It also can mean that the return values do not have to be agreed upon before hand. So there seem to be some possibilities for reduced dependency and increased modularization.
Hockey wrote:I think you misunderstand the intent of exceptions - at least according to industry experts:
First of all, it is just one expert. You can't just jump from one guy's opinion to the consensus of "industry experts". And yes, I am proposing that this discussion is more relevant to PHP today than Bruce Eckel's essentially performance based comments about C++ in 2001. He had his opinion then (with his reasons), and we have our opinions today (with our reasons).
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

I've determined that it is not appropriate for my system to utilize try-catch blocks at every corner...so I will deliberate no more. :P

You, and others that agree with you, can replace all your IF statements with try-catch blocks for all I care...hahaha...that sounded harsh...I don't mean it with quite that sharp a tongue (obviously I hope the best for all your projects).


Merry Christmas :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

To clarify, no one but you suggested "to utilize try-catch blocks at every corner" or to "replace all your IF statements with try-catch blocks" so those comments are not germane to this conversation. The question (back to the OP) was how to use the unique features of the try/catch conditional.
(#10850)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Ok, lets try a game of boolean vs try/catch in a fairly interchangable manner.

Imagine you want to deduct credit from a customer's account. It wouldn't be uncommon to see this sort of thing in PHP4.

Code: Select all

if ($creditAccount->debit($price)) {
  //success
  $response->redirect('?checkoutResponse=success');
} else {
  $response->redirect('?checkoutResponse=insufficient_credit');
}
Now in PHP5 we'd have the option of doing it with a new construct.

Code: Select all

try {
  $creditAccount->debit($price);
  $response->redirect('?checkout=success');
} catch (InsufficientCreditException $e) {
  $response->redirect('?checkout=insufficient_credit');
}
The advantage with the second version is that (like Return-codes) you can have various types of exception bubbled out of the same block of code and you can add custom logic to your exception (say, including the missing balance).

Aside from something as interchangable as that, they have a different behaviour when the try block wraps a larger segment of code since the flow can be broken at any point as an exception bubbles up the stack.

Exceptions get used in Java as "interrupt" signals to other Threads too.

It's almost like try/catch should be one construct and Exceptions should be just something which utilizes try/catch. So we can throw objects like Exceptions, except these objects have some implementation which is not semantically related to error situations.... if that feature were available would we stop having this debate?

Code: Select all

try {
  //something
} catch (ThrowableObject $o) {
  //
}
Post Reply