Databases
StackOverflow2013
Postsdbo
POCatching Python runtime errors only
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POCatching Python runtime errors only
    primarykey
    data
    text
    <p>I find myself handling exceptions without specifying an exception type when I call code that interacts with system libraries like shutil, http, etc, all of which can throw if the system is in an unexpected state (e.g. a file locked, network unavailable, etc)</p> <pre><code>try: # call something except: print("OK, so it went wrong.") </code></pre> <p>This bothers me because it also catches <code>SyntaxError</code> and other exceptions based in programmer error, and I've seen recommendations to avoid such open-ended exception handlers.</p> <p>Is there a convention that all runtime errors derive from some common exception base class that I can use here? Or anything that doesn't involve syntax errors, module import failures, etc.? Even <code>KeyError</code> I would consider a bug, because I tend to use dict.get() if I'm not 100% sure the key will be there.</p> <p>I'd hate to have to list every single conceivable exception type, especially since I'm calling a lot of supporting code I have no control over.</p> <p><strong>UPDATE:</strong> OK, the answers made me realize I'm asking the wrong question -- what I'm really wondering is if there's a Python convention or explicit recommendation for library writers to use specific base classes for their exceptions, so as to separate them from the more mundane <code>SyntaxError</code> &amp; friends. </p> <p>Because if there's a convention for library writers, I, as a library consumer, can make general assumptions about what might be thrown, even if specific cases may vary. Not sure if that makes more sense?</p> <p><strong>UPDATE AGAIN</strong>: Sven's answer finally led me to understand that instead of giving up and catching everything at the top level, I can handle and refine exceptions at the lower levels, so the top level only needs to worry about the specific exception type from the level below.</p> <p>Thanks!</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USKim Gräsman
    1. USKim Gräsman
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    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. POCatching Python runtime errors only
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POCatching Python runtime errors only
      1. This table or related slice is empty.
      1. VTDownMod
    3. VO
      singulars
      1. POCatching Python runtime errors only
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks, I had searched but didn't manage to weed out a clear answer. Where is the divide between parsing/syntax/programmer errors and runtime errors?
      singulars
      1. POCatching Python runtime errors only
      1. USKim Gräsman
    2. CONote that you can't usually catch a `SyntaxError` -- it will be thrown when *compiling* the source, long before it is executed. The only cases a `SyntaxError` can be catched if your `try` block contains `import`, `exec`, `execfile()` or `eval()`.
      singulars
      1. POCatching Python runtime errors only
      1. USSven Marnach
    3. CO@SvenMarnach: Huh, I was sure I'd seen these type-less handlers catch even syntax errors, but it could've been something else, more subtle. I don't have a clean example handy. Thanks for the correction.
      singulars
      1. POCatching Python runtime errors only
      1. USKim Gräsman
 

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