On Tuesday, 27 June 2017 at 06:10:52 UTC, Tobias Müller wrote:
I honestly don't understand how people that care a great deal
about expressive type systems can be so opposed to checked
exceptions. After all they wouldn't use 'object' for everything
either.
Tobi
I think there is a threshold. For example, personally I am
against the compiler refusing to compile because of an unused
variable, or import clause. Why, because they get in the way of
making changes. I don't want to pacify the compiler as I progress
through the development process. Generally when the compiler
complains about a type mismatch I actually forgot to make
additional changes to make the new thing work.
Checked exceptions do the same thing. Call a new function,
propagate the exception just to determine if it is a desired
change. This very much can lead to attempting to pacify without
properly handling.
This discussion seems to emphasize the ability to handle every
exception type. There are certainly times I've utilized the
ability to handle different types of exception in different ways,
but it isn't the norm. This is likely because generally I find
Exception to crop up because of programming logic bugs rather
than true exceptions and in the other cases I'm not using the
type of exception to change how I deal with a problem; if my Json
parsing throws a Conversion exception I'm not going to handle it
differently than when it throws an Invalid Token exception.
I however don't have much experience managing checked Exceptions.
I remember back in the day trying to fix the long list of
exceptions my functions could throw. I'd commonly use throws
Exception, pondered on wrapping exceptions into my own exception
that would then be thrown. Neither of these would be helpful to
the original points, adding exceptions should break the contract
and you should be able to catch specific exceptions. How is the
ever expanding exception list of static void Main managed by
others?
