Performance implications of constructing an exception

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

User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Performance implications of constructing an exception

Post by Ollie Saunders »

Code: Select all

$ex = catch {
  // some code that might thrown an exception.
  while (...) {
     // code in the while loop that could cause an exception, ending the loop.
     $ex = catch {
         // code that should not end the while loop
     }
     // inner error handler (the loop could continue in the event of a not so exceptional exception)
   } // end of while loop
}
// The outer error handler. Catch exceptions that should end the while loop.
User avatar
PHPHorizons
Forum Contributor
Posts: 175
Joined: Mon Sep 14, 2009 11:38 pm

Re: Performance implications of constructing an exception

Post by PHPHorizons »

That doesn't make sense to me because you'd have to throw an exception to even begin that whole process.

I am assuming that your "catch {} " is what catches an exception right? So to begin executing any of that code, one is required to throw an exception.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Performance implications of constructing an exception

Post by Ollie Saunders »

No, that version of catch would execute the code inside as try does, only it would also catch any exceptions that occur too.
User avatar
arjan.top
Forum Contributor
Posts: 305
Joined: Sun Oct 14, 2007 4:36 am
Location: Hoče, Slovenia

Re: Performance implications of constructing an exception

Post by arjan.top »

You cant catch exceptions by type in your example

Code: Select all

 
<?php
 
try {
   while (...) {
     try {
     } catch (SomeException $error) {
     }
   }
} catch (SomeOtherException $error) {
 
}
 
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Performance implications of constructing an exception

Post by Ollie Saunders »

Previous posts in this thread, arjan.top should have read before posting:
viewtopic.php?p=569533#p569533
viewtopic.php?p=569580#p569580
User avatar
arjan.top
Forum Contributor
Posts: 305
Joined: Sun Oct 14, 2007 4:36 am
Location: Hoče, Slovenia

Re: Performance implications of constructing an exception

Post by arjan.top »

declaring type as string is not a good idea, and if you catch an exception you would want to do something
your example does return exception? so you would have to write:
$e = catch { somethin() };
if($e) {
//do something
}
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Performance implications of constructing an exception

Post by Jenk »

arjan.top.. that is not valid syntax.

Code: Select all

try {
  something();
} catch (Exception $e) {
  // do something
}
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Performance implications of constructing an exception

Post by Jenk »

Ollie Saunders wrote:I don't see why "try" is necessary at all.
Primarily because you need to nomimate which area of the code you are catching for, and secondly, so you can specify multiple catch blocks for the same try block.

Code: Select all

try {
  foo();
} catch (SpecificException $a) {
} catch (ADifferentSpecificException $b) {
} catch (Exception $e) {
  // generic (i.e. 'unknown') exception
}
An example I often see if when accessing a database, you can have DuplicateKeyException, ConnectionNotValidException, Column/Table/DatabaseDoesNotExist exception.. etc. and you may wish to handle the exception differently, based upon which exception was thrown.
User avatar
arjan.top
Forum Contributor
Posts: 305
Joined: Sun Oct 14, 2007 4:36 am
Location: Hoče, Slovenia

Re: Performance implications of constructing an exception

Post by arjan.top »

Jenk wrote:arjan.top.. that is not valid syntax.
it' example based on ollie's syntax
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Performance implications of constructing an exception

Post by Jenk »

Ah, now I understand. :)

Ollie.. the try block is what you want to try and do. The catch block is what you want to do after, and only if the exception has been thrown.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Performance implications of constructing an exception

Post by Ollie Saunders »

Hehe, I managed to confuse everyone. Anyway, thanks for making the multiple catch block point, I'd forgotten about that.
declaring type as string is not a good idea
Huh? What am I declaring as a string?
and if you catch an exception you would want to do something
your example does return exception? so you would have to write:
$e = catch { somethin() };
if($e) {
//do something
}
Yep, a catch block and an if block. Two blocks, just like try and catch; barely worse at all.

If you have another argument about why this is a bad idea, I probably won't respond to it. You're thinking aggressively: putting all your effort into proving why I'm wrong, instead of exploring the entire issue objectively.
User avatar
arjan.top
Forum Contributor
Posts: 305
Joined: Sun Oct 14, 2007 4:36 am
Location: Hoče, Slovenia

Re: Performance implications of constructing an exception

Post by arjan.top »

Huh? What am I declaring as a string?
my mistake, misunderstood the example on the first page
Yep, a catch block and an if block. Two blocks, just like try and catch; barely worse at all.
yes, but with try/catch you get clear separation what would happen if exception is thrown, with your syntax if statement that would handle it could be anywhere
If you have another argument about why this is a bad idea, I probably won't respond to it. You're thinking aggressively: putting all your effort into proving why I'm wrong, instead of exploring the entire issue objectively.
No, I'm not putting all my effort into why you're wrong, I just don't see any advantage over try/catch
User avatar
PHPHorizons
Forum Contributor
Posts: 175
Joined: Mon Sep 14, 2009 11:38 pm

Re: Performance implications of constructing an exception

Post by PHPHorizons »

arjan.top wrote:[snipped]
$e = catch { somethin() };
if($e) {
//do something
}

Using "catch" for the "try" portion is missleading. If you were going to do things this way, this next example might be more appropriate:

Code: Select all

$e = try{ somethin() };
if($e) {
 //do something
}
I don't see any new functionality though. This "syntatic sugar" just gives a different way to do something that can already easily be done. There's almost no chance at all for this to actually be added to php.

Cheers
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Performance implications of constructing an exception

Post by josh »

Jenk wrote: you need to nomimate which area of the code you are catching for, and secondly, so you can specify multiple catch blocks for the same try block.

lol, thank you... reading the rest of this thread was like :dubious: It's important to understand what exceptions are supposed to do. Eliminating "try" made absolutely no sense whatsoever

This entire thread makes no sense after the first few posts
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Performance implications of constructing an exception

Post by Ollie Saunders »

I'm so badly in the wrong place here. I don't think you'll hear from me again. Goodbye.
Post Reply