# Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

- Thread: https://externals.io/message/86232
- Original archive: https://news-web.php.net/php.internals/86232
- Started by Xinchen Hui on 2015-05-15T14:38:54+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #86232 — Xinchen Hui — 2015-05-15T14:38:54+00:00

URL: https://externals.io/message/86232#86232

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/

---

## #86234 — Dan Ackroyd — 2015-05-15T16:35:44+00:00

URL: https://externals.io/message/86232#86234 · In reply to: #86232

> 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.

cheers
Dan

---

## #86235 — Xinchen Hui — 2015-05-15T17:12:07+00:00

URL: https://externals.io/message/86232#86235 · In reply to: #86234

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 one

Thanks
> 
> cheers
> Dan

---

## #86236 — Dan Ackroyd — 2015-05-15T17:41:43+00:00

URL: https://externals.io/message/86232#86236 · In reply to: #86235

> > […]
> 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

---

## #86247 — Xinchen Hui — 2015-05-16T15:06:18+00:00

URL: https://externals.io/message/86232#86247 · In reply to: #86236

Hey:


> 
> > […]
>
> 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.
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/

---

## #86249 — Ryan Pallas — 2015-05-16T17:00:37+00:00

URL: https://externals.io/message/86232#86249 · In reply to: #86236

On Fri, May 15, 2015 at 11:41 AM, Dan Ackroyd <danack@basereality.com>
wrote:

> 
> > […]
> 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.
>
>
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

---

## #86255 — Dan Ackroyd — 2015-05-16T18:47:52+00:00

URL: https://externals.io/message/86232#86255 · In reply to: #86249

> 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

---

## #86281 — Dan Ackroyd — 2015-05-17T00:20:13+00:00

URL: https://externals.io/message/86232#86281 · In reply to: #86232

> 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:
>    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