Drop custom DBAL exceptions

[foxycode]

Related to #238

This was little difficult for me. I am not sure about few things. See my comments in code.

[foxycode]

In parent, connect is not called. Is it here because of custom exception? Can I drop it?

[fprochazka]

It is indeed unneccesary. It was here only because older version of doctrine had it.

[fprochazka]

There is a bit of a problem with this. The panel and exception renderer require to know which connection generated the exception. Because for rendering of the exception, the Platform object of that connection is required.

So those methods that you've removed from Connection need to stay there, but changed, something like this

    public function executeQuery($query, array $params = array(), $types = array(), QueryCacheProfile $qcp = NULL)
    {
        try {
            return parent::executeQuery($query, $params, $types, $qcp);

        } catch (\Exception $e) {
            if ($this->panel) {
                $this->panel->queryFailed($e);
            }
            throw $e;
        }
    }

This way, the custom exceptions are gone, but we still can bind the exception with the relevant connection object.

---

And as the Panel is growing uncontrollably, I'd preffer breaking it into several classes.

• Only the SQL panel stuff - which the part that is registered as SQLLogger and renders tracy bar panel
• Only the exception bluescreen rendering stuff with context (SQL errors, metadata mapping errors, ...)
• Only rendering context-less exceptions.

That way, we can register the second and third one in production without the first one.

The "context exceptions panel" must also be somehow passed to connection, so connection can mark the exceptions, and also passed to the custom PDOStatement that you've removed, so also that thing can mark the exceptons.

Does it make sense?

---

Also, it would be beneficial to look first how symfony is solving this - if they ignore the problem completely, or if they somehow mark the exceptions too.

[fprochazka]

I wouldn't wanna drop the filling parameters back into the SQL, because I consider it way too comfortable, to be able to just copy the SQL statement and run it directly in Adminer.

[foxycode]

@fprochazka I expected it wouldn't be that simple. I try to rework it.

That do you meant by your last comment?

[fprochazka]

@foxycode well, there is always an option to simply drop the support for rendering SQL queries with parameters inlined, but I wouldn't wanna do that.

[foxycode]

@fprochazka Ok, I understand. But wouldn't be simplier remove panel from this repo and move work to new repository now?

[fprochazka]

@foxycode I don't see how it would make it simpler :)

The panel itself and context-free bluescreen renderers could in fact be separated right now probably, but the "exceptions bluescreen" would have to stay here, with the extended connection, since there would be no way otherwise to mark the exceptions

[foxycode]

@fprochazka I was thinking about separating Tracy integration including extended connection to separate package, but now I see it's not that good idea. I'll think about this more a try to fix it.

[foxycode]

@fprochazka I start with Panel reworking in separate PR. Can you please answer to other questions I had in code?

[fprochazka]

I belive I've answered all your questions now :)