http://www.doctrine-project.org/jira This file is an XML representation of an issue en-us 5.2.7 850 21-02-2013 http://www.doctrine-project.org/jira/browse/DBAL-407 Doctrine DBAL <p>It's currently rather hard to figure out what went wrong when for example a DBALException was thrown. You have to actually match the message in it, or read the status code of the -&gt;getPrevious() exception, which can be different for all drivers (as <a href="https://github.com/jackalope/jackalope-doctrine-dbal/issues/80" class="external-link">https://github.com/jackalope/jackalope-doctrine-dbal/issues/80</a> shows).</p> <p>I'd suggest creating new exception classes for all situations and throwing them instead. If they extend the DBAL Exception and pass the message to it as it is right now, there will be no BC break.</p> <p>If this were to be done, on which branch should this be applied?</p> DBAL-407

Refactor exceptions

Improvement Major Open Unresolved All Benjamin Eberlei Bart van den Burg Mon, 7 Jan 2013 18:09:34 +0000 Mon, 6 May 2013 06:10:18 +0000 Drivers Platforms Schema Managers 1 4 <p>This should be done in the master branch.</p> <p>Another solution, avoiding to create many classes, would be to use the exception code, which is always kept as 0 currently (the default value of the Exception class). You could have a code for each case (with constants in the DBALException class) and then checking <tt>$e-&gt;getCode()</tt> to identify what went wrong.</p> <p>I'd prefer actual named exceptions. It makes catching them simpler. However, adding some code defined in DBAL would be an acceptable alternative. </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">try</span> { /* ... /* } <span class="code-keyword">catch</span> (NoSuchTableException $e) { <span class="code-comment">// <span class="code-keyword">do</span> something </span>} <span class="code-keyword">catch</span> (DuplicateKeyException $e) { <span class="code-comment">// <span class="code-keyword">do</span> something <span class="code-keyword">else</span> </span>} </pre> </div></div> <p>v.s.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">try</span> { /* ... /* } <span class="code-keyword">catch</span> (DBALException $e) { <span class="code-keyword">if</span> ($e-&gt;getCode() == DBALException::NO_SUCH_TABLE) { <span class="code-comment">// <span class="code-keyword">do</span> something </span> } elseif ($e-&gt;getCode() == DBALException::DUPLICATE_KEY) { <span class="code-comment">// <span class="code-keyword">do</span> something <span class="code-keyword">else</span> </span> } <span class="code-keyword">else</span> { <span class="code-keyword">throw</span> $e; } } </pre> </div></div> <p>I would also prefer named exceptions. You're going to have a lot of problems providing the "code" value in DBALException in any case: SQLSTATE codes are alphanumeric, and will cause warnings/errors when creating new exception.</p> <p>Besides we can get the SQL state code now:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> try { // ... } catch (\Doctrine\DBAL\DBALException $e) { $code = $e-&gt;getPrevious()-&gt;getCode(); // do stuff with $code } </pre> </div></div> <p>The problem is that there are a lot of error codes defined in the ANSI SQL standard: <a href="http://www.postgresql.org/docs/9.2/static/errcodes-appendix.html" class="external-link">http://www.postgresql.org/docs/9.2/static/errcodes-appendix.html</a></p> <p>Maybe throwing an specific exception for each "class" of SQLSTATE codes? So if the error code from a PDO exception starts with 23, DBAL would throw `\Doctrine\DBAL\Exception\IntegrityConstraintViolationException`.</p> <p>This also seems like the logic to handle throwing exceptions should be contained in the platforms as some implementations may differ. You could have a method in `AbstractPlatform` that takes care of the ANSI SQLSTATE error code classes and leave it up subclasses to deal with platform specific cases. Whenever `Connection` catches a `PDOException`, dispatch it to the platform to deal with.</p> <p>Example: <a href="https://gist.github.com/chrisguitarguy/e021918900e93dca304d" class="external-link">https://gist.github.com/chrisguitarguy/e021918900e93dca304d</a></p> <p>Thoughts?</p> <p>I have implemented a thing of that kind in a personal project (on top of Doctrine). It is <b>really</b> useful to be able to catch a ForeignKeyViolationException, and get with entity/field caused the problem (for that my EntityManager wrapper parse the exception message).</p> <p>However, note that exception codes differ from DB engines. In my case, I did it quick and used MySQL error codes, but managing different RDBMS implies more work.</p>