The main relevance of classifying errors properly in python is for try/except. Generally, a try/except should be tight both in code guarded and in errors caught. An `except RuntimeError` is almost certainly a bad idea. `except ZeroDivisionError` looks quite reasonable. `except ValueError` or `except ArithmeticError` can already easily catch a little too much. `except TypeError` looks very suspicious when what is intended to be caught is an object (of the right type) to which a (partial) "inversion" map cannot be applied. "NotImplemented" should probably not be caught either: implementing the missing functionality is ideally the way to avoid that error from occurring.
Error objects do have more info than just their type and an except clause can investigate this and decide to reraise. That's a huge pain to program (and potentially slow), so in practice that's almost never done. The type of an error is in practice the only granularity for try/except. Reclassifying errors should probably happen with an eye towards the utility for try/except. That means that reclassifying existing error will break existing code, so you better have a very good reason. For "RuntimeError" I agree, because there the developer (unintentionally?) signals "this shouldn't be caught". So you'll have to go in, analyse the intent and reassess if that error should indeed not be caught. For the other ones it depends: if it's an object that can end up in polymorphic code then aligning errors makes sense, but otherwise the pain of breakage probably means the change is not worth it. On Friday 9 February 2024 at 01:00:45 UTC-8 Travis Scrimshaw wrote: > You're misunderstanding what a catch-all means. It means *any* type (of > error) is reasonable. To put it mathematically, catch-all means union (of > sets), but the Python doc means difference (of sets). > > An assertion is slightly different. It can (in principle) be turned off > and is just used for internal checking. While there is large overlap, it is > not quite the same (e.g., if code is assuming a certain conjecture, it > should not use assert to check validity of assumptions). > > Best, > Travis > > > On Friday, February 9, 2024 at 1:44:23 PM UTC+9 dmo...@deductivepress.ca > wrote: > >> Description of RunTimeError from docs.python.org: "Raised when an error >> is detected that doesn’t fall in any of the other categories. The >> associated value is a string indicating what precisely went wrong." >> >> It is for exceptions that cannot be categorized, so I believe it is >> indeed just a catch-all error (but must have a description), and there is >> no expectation that such an error is particularly serious. (A situation >> where "an assumption that I never expected to be violated fails" can raise >> AssertionError.) >> >> On Thursday, February 8, 2024 at 10:14:33 PM UTC-5 David Roe wrote: >> >>> On Thu, Feb 8, 2024 at 8:18 PM 'Travis Scrimshaw' via sage-devel < >>> sage-...@googlegroups.com> wrote: >>> >>>> For RuntimeError, I would make it sound like it tells you there is >>>> serious error occurring as it doesn't fall into any other error >>>> categories. >>>> This actually makes it the opposite of a catchall error. >>>> >>> >>> The main scenario when I use a RuntimeError is when an assumption that I >>> never expected to be violated fails. I agree with Travis that catchall is >>> not the right description for this error type. >>> David >>> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/30baa52d-5784-4db4-818a-cd9a571298b4n%40googlegroups.com.
