Databases
StackOverflow2013
Postsdbo
POE_NOTICE ?== E_DEBUG, avoiding isset() and @ with more sophisticated error_handler
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POE_NOTICE ?== E_DEBUG, avoiding isset() and @ with more sophisticated error_handler
    primarykey
    data
    text
    <p>Which better ways exist to avoid an abundance of <code>isset()</code> in the application logic, and retain the ability to see debug messages (E_NOTICE) <em>when</em> required?</p> <p>Presumption first: E_NOTICE is not an error, it's a misnomer and should actually be E_DEBUG. However while this is true for unset variables (PHP is still a scripting language), some file system functions etc. throw them too. Hence it's desirable to <em>develop</em> with E_NOTICEs on.</p> <p>Yet not all debug notices are useful, which is why it's a common (unfortunate) PHP idiom to <a href="https://stackoverflow.com/questions/1960509/isset-and-empty-make-code-ugly">introduce <code>isset()</code></a> and @ throughout the application logic. There are certainly many valid use cases for isset/empty, yet overall it seems <strong>syntactic salt</strong> and can actually obstruct debugging.</p> <p>That's why I currently use an error_reporting bookmarklet and a dumb on/off switch:</p> <pre><code>// javascript:(function(){document.cookie=(document.cookie.match(/error_reporting=1/)?'error_reporting=0':'error_reporting=1')})() if (($_SERVER["REMOTE_ADDR"] == "127.0.0.1") and $_COOKIE["error_reporting"]) { error_reporting(E_ALL|E_STRICT); } else {/* less */} </code></pre> <p>However that still leaves me with the problem of having too many notices to search through once enabled. As workaround I could utilize the @ error suppression operator. Unlike isset() it does not completely kill debugging options, because a custom error handler could still receive suppressed E_NOTICEs. So it might help to separate <em>expected</em> debug notices from potential issues.</p> <p>Yet that's likewise unsatisfactory. Hence the question. Does anyone use or know of a more sophisticated PHP error handler. I'm imagining something that:</p> <ul> <li>outputs unfiltered errors/warnings/notices (with CSS absolute positioning?)</li> <li>and AJAX-whatnot to allow client-side inspection and suppression</li> <li>but also saves away a filtering list of <em>expected and "<strong>approved</strong>"</em> notices or warnings.</li> </ul> <blockquote> <p>Surely some framework must already have a user error handler like that.</p> </blockquote> <ul> <li>Basically I'm interested in warning / notice management.</li> <li>Full E_NOTICE supression is really not desired.</li> <li>E_NOTICES <strong>are</strong> wanted. Just less of them. Per default highlight the ones I might care about, not the expected.</li> <li>If I run without ?order= parameter, an expected NOTICE occours. Which due to be expected I do not need to informed about more than once.</li> <li>However when in full debugging mode, I do wish to see the presence of undefined variables through the presence (or more interestingly absence) of said debug notices. -> That's what I think they are for. Avoiding isset brings language-implicit print statements.</li> <li>Also realize this is about use cases where ordinary PHP form handling semantics are suitable, not application areas where strictness is a must.</li> </ul> <p>Oh my, someone please help rewrite this. Lengthy explanation fail.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USmario
    plurals
    1. PL
      singulars
      1. LTLinked
    1. 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. POE_NOTICE ?== E_DEBUG, avoiding isset() and @ with more sophisticated error_handler
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POE_NOTICE ?== E_DEBUG, avoiding isset() and @ with more sophisticated error_handler
      1. USmario
      1. VTBountyStart
    3. VO
      singulars
      1. POE_NOTICE ?== E_DEBUG, avoiding isset() and @ with more sophisticated error_handler
      1. This table or related slice is empty.
      1. VTUpMod
    1. COPersonally, I feel your presumption is wrong. My position is that they are thrown by undefined array indexes or variable usage. If a variable is undefined, accessing it **is** an error. Yes, a lot of people just turn notices off and never use `isset`. Is that wrong? No. But you do lose a lot of valid undefined variable errors (such as variable mis-spellings)... So while it's not "wrong", I think not using it (`isset`, and developing notice-free code) is lazy and not a great practice (even bordering on "bad practice")...
      singulars
      1. POE_NOTICE ?== E_DEBUG, avoiding isset() and @ with more sophisticated error_handler
      1. USircmaxell
    2. CO@ircmaxell My take is that it really depends. There is logic where a NULL or undef variable can bite you in the butt quite exceptionally. For the majority of PHP code, dealing with form input etc, it doesn't seem that farfetched to accept PHPs dynamic semantics where undefined vars are **not** errors. Again, it depends. Not trying to avoid isset at all costs. Also I do want to retain the notices actually, basically as NULL assertions. Just less of them.
      singulars
      1. POE_NOTICE ?== E_DEBUG, avoiding isset() and @ with more sophisticated error_handler
      1. USmario
    3. COThat's fair. But if you go that far, why are you even accessing raw form input at all? Why aren't you using a library which can handle validation, cleaning, etc for you? Instead of `$foo = $_GET['bar']`, `$foo = $request->get('bar');`... Then you're not littered everywhere with `isset()`, and you actually make it more readable. While I agree that it's not "farfetched to accept PHPs dynamic...", I would argue whether it's good or not to do so. Predefining variables and checking for existence not only makes it more readable, it also clarifies your intent (which makes debugging easier).
      singulars
      1. POE_NOTICE ?== E_DEBUG, avoiding isset() and @ with more sophisticated error_handler
      1. USircmaxell
 

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