Databases
StackOverflow2013
Postsdbo
POCustom Exception Messages: Best practices
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POCustom Exception Messages: Best practices
    primarykey
    data
    text
    <p>Wondering how much effort I should go to forcing useful debugging information when creating exception messages, or should I just trust the user to supply the right info, or defer the information gathering to an exception handler?</p> <p>I see a lot of people people doing their exceptions like:</p> <pre><code>throw new RuntimeException('MyObject is not an array') </code></pre> <p>or extending the default exceptions with custom exceptions that don't do much but change the name of the exception:</p> <pre><code>throw new WrongTypeException('MyObject is not an array') </code></pre> <p>But this doesn't supply much debugging info... and doesn't enforce any kind of formatting with the error message. So you could end up with exactly the same error producing two different error messages... eg "Database connection failed" vs "Could not connect to db"</p> <p>Sure, if it bubbles to the top, it'll print the stack trace, which is useful, but it doesn't always tell me everything I need to know and usually I end up having to start shooting off var_dump() statements to discover what went wrong and where... though this could be somewhat offset with a decent exception handler.</p> <p>I'm starting to think about something like the code below, where I <em>require</em> the thrower of the exception to supply necessary args to produce the correct error message. I'm thinking this might be the way to go in that:</p> <ul> <li>Minimum level of useful information must be supplied</li> <li>Produces somewhat consistent error messages</li> <li>Templates for exception messages all in the one location (exception classes), so easier to update the messages...</li> </ul> <p>But I see the downside being that they are harder to use (requires you look up exception definition), and thus might discourage other programmers from using supplied exceptions...</p> <p>I'd like some comment on this idea, &amp; best practices for a consistent, flexible exception message framework.</p> <pre><code>/** * @package MyExceptions * MyWrongTypeException occurs when an object or * datastructure is of the incorrect datatype. * Program defensively! * @param $objectName string name of object, eg "\$myObject" * @param $object object object of the wrong type * @param $expect string expected type of object eg 'integer' * @param $message any additional human readable info. * @param $code error code. * @return Informative exception error message. * @author secoif */ class MyWrongTypeException extends RuntimeException { public function __construct($objectName, $object, $expected, $message = '', $code = 0) { $receivedType = gettype($object) $message = "Wrong Type: $objectName. Expected $expected, received $receivedType"; debug_dump($message, $object); return parent::__construct($message, $code); } } </code></pre> <p>....</p> <pre><code>/** * If we are in debug mode, append the var_dump of $object to $message */ function debug_dump(&amp;$message, &amp;$object) { if (App::get_mode() == 'debug') { ob_start(); var_dump($object); $message = $message . "Debug Info: " . ob_get_clean(); } } </code></pre> <p>Then used like:</p> <pre><code>// Hypothetical, supposed to return an array of user objects $users = get_users(); // but instead returns the string 'bad' // Ideally the $users model object would provide a validate() but for the sake // of the example if (is_array($users)) { throw new MyWrongTypeException('$users', $users, 'array') // returns //"Wrong Type: $users. Expected array, received string } </code></pre> <p>and we might do something like a nl2br in a custom exception handler to make things nice for html output.</p> <p>Been reading: <a href="http://msdn.microsoft.com/en-us/library/cc511859.aspx#" rel="noreferrer">http://msdn.microsoft.com/en-us/library/cc511859.aspx#</a></p> <p>And there is no mention of anything like this, so maybe it's a bad idea... </p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USGEOCHET
    1. UStimoxley
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POCustom Exception Messages: Best practices
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POCustom Exception Messages: Best practices
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POCustom Exception Messages: Best practices
      1. USVirtuosiMedia
      1. VTFavorite
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload