I keep using a syntax of . for a reason. It
is piggybacking on an already established exception and in reality just
providing a sub-type that could easily be used by the except block to determine
acceptance. An easy implementation of this still constructs
that just has a property of subtype so
I am not advocating removing exception objects so inheritance is still there if
needed. As for the data class and exceptions being just two lines, again, I
think that makes my point about the boilerplate for most exceptions. Most of
the time they are being created just to have a constant to comp
Steven,
Thanks for the responses. In response to your responses:
Steven D'Aprano wrote:
> Hi jmward01,
> I'm not really sure what you mean by "boilerplate heavy objects".
> Boilerplate generally applies to the amount of source code you have to
> write. I d
Greg Ewing wrote:
> > You can reduce the amount of boilerplate by doing something
> like this:
> class MySpecialException(Exception):
> pass
> def handle_my_special_exception(a, b, c, d, e, f):
>
> try:
> if some_test_that_fails(variables):
>raise MySpecialException(a, b
I think this can stand on its own without needing to be borrowed from another
language. This pattern of needing special objects for exceptions causes me to
avoid them since the boilerplate overhead discourages their use.
___
Python-ideas mailing list --
I generally find exception objects are really just boilerplate heavy objects
masking what I really want them to be, function calls:
class MySpecialException(Exception):
def __init__(self, some, variables, i, am, tracking):
self.some = some
...
...
try:
if some_test_that_fails(variab
