Hey:
as described in https://bugs.php.net/bug.php?id=69640&thanks=1
instead of fixing it by exam the error type, I'd prefer to
disallow initializing a engine exception from user land..
like if you try to initialize a engine/type/parser exception, an `E_ERROR` of:
PHP Fatal error: Initilizing a system exception is disallowed
will be trigged..
what do you think?
thanks
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
as described in https://bugs.php.net/bug.php?id=69640&thanks=1 instead of fixing it by exam the error type, I'd prefer todisallow initializing a engine exception from user land..
How would that work when people want to write unit/integration tests
to test the behaviour of a module when an EngineException is thrown?
If you can't create a certain type of exception, it would mean that
some code is basically untestable...which seems bad.
cheers
Dan
Hey：
Hey:
as described in https://bugs.php.net/bug.php?id=69640&thanks=1
instead of fixing it by exam the error type, I'd prefer to
disallow initializing a engine exception from user land..How would that work when people want to write unit/integration tests
to test the behaviour of a module when an EngineException is thrown?If you can't create a certain type of exception, it would mean that
some code is basically untestable...which seems bad.
You can not creat it directly, but you can trigger the engine to throw one
Thanks
cheers
Dan
How would that work when people want to write unit/integration tests
to test the behaviour of a module when an EngineException is thrown?If you can't create a certain type of exception, it would mean that
some code is basically untestable...which seems bad.
You can not creat it directly, but you can trigger the engine to throw one
I don't think having to do something like:
eval("<?php echo bar(};");
to test ParseExceptions is a good plan.
Can you say what the actual problem is that would be solved by not
allowing them to be initialized from userland? It seems an artificial
limitation that just makes it harder to test programs.
cheers
Dan
Hey:
How would that work when people want to write unit/integration tests
to test the behaviour of a module when an EngineException is thrown?If you can't create a certain type of exception, it would mean that
some code is basically untestable...which seems bad.
You can not creat it directly, but you can trigger the engine to throw oneI don't think having to do something like:
eval("<?php echo bar(};");
to test ParseExceptions is a good plan.
Can you say what the actual problem is that would be solved by not
allowing them to be initialized from userland? It seems an artificial
limitation that just makes it harder to test programs.
EngineException/TypeException/ParserException is designed for internal
errors only.
if then are used in user land. they may cause lots of side affects,
this bug is one of them...
thanks
cheers
Dan
--
Xinchen Hui
@Laruence
http://www.laruence.com/
On Fri, May 15, 2015 at 11:41 AM, Dan Ackroyd danack@basereality.com
wrote:
How would that work when people want to write unit/integration tests
to test the behaviour of a module when an EngineException is thrown?If you can't create a certain type of exception, it would mean that
some code is basically untestable...which seems bad.
You can not creat it directly, but you can trigger the engine to throw
oneI don't think having to do something like:
eval("<?php echo bar(};");
to test ParseExceptions is a good plan.
Can you say what the actual problem is that would be solved by not
allowing them to be initialized from userland? It seems an artificial
limitation that just makes it harder to test programs.
Why do you want to test parse exceptions? Lint your code before you run it
and you won't have any. Additionally, your code doesn't run until after
parsing is finished, so its not something that it makes sense to "test"
since your code won't ever execute then... maybe I'm missing something
obvious, but I've never wanted to test the parser, just my code written for
it.
cheers
Dan
Why do you want to test parse exceptions? Lint your code before you run it
and you won't have any. ... maybe I'm missing something
obvious,
Yeah, there's been a misunderstanding. I'm not talking about wanting
to test whether my code generates parse exceptions, I'm talking about
testing whether the code that catches parse exceptions behaves
correctly.
e.g. Wordpress should be catching ParseExceptions (and other
EngineExceptions) generated by plugins and reporting those plugins as
being problematic.
The code that handles those exceptions needs to tested that it behaves
correctly, which requires the appropriate exception being generated
when the test is run. Although people could use a nasty hack such as
eval("<?php echo bar(};");, that seems moderately horrific.
cheers
Dan
I'd prefer to
disallow initializing a engine exception from user land..
like if you try to initialize a engine/type/parser exception, anE_ERRORof:
what do you think?
Someone reminded me that TypeExceptions are almost certainly going to
be re-used by users for the cases where PHP's type system isn't
powerful enough to handle their use cases:
function handleFooOrBar($instance) {
if(!$instance instanceof Bar && !$lol instanceof Foo) {
throw new TypeException('$instance must be either an instance
of Bar or Foo');
}
...
}
Re-using the built-in TypeException for this would be the right thing
to do and so it needs to be creatable in userland.
cheers
Dan