I have read the main arguments in the suggested thread.
I understand that this is a false sense of safety. But such a syntax (not the one I suggested, but a more appropriate one) would make the code more self-documenting.
A possible use case: documenting in fastapi, etc.
If every function call has to be wrapped in a try/except, exceptions are no advantage over return codes. Every function could be defined to return a tuple of either (True, return value) or (False, error) and every call MUST check the return value. There are languages that are built this way, and they succeed because they don’t have the additional overhead of exception management. Requiring a try/except would be as bad as removing exceptions from the language altogether, but still paying the cost. It’s the worst of both worlds.
Apparently my idea is misunderstood or explained.
I’m not suggesting to change the python API, and I’m not suggesting to redo anything. I’m just proposing to use it for annotation. It has no real effect on error handling and python Exceptions approach.
I was simply explaining what you were unclear on from the original thread, and what it would mean for exceptions to become nothing more than a lower-performance version of tuple returns in that way.
The idea is still a bad one for all the reasons given in the original thread. “It can be fixed” is not true because the lack of checked exceptions is not a problem to be solved. If you think otherwise, respond to ALL of the arguments from that thread.
IOError is a subclass of Exception, so all you’re really saying here is that this could raise Exception, which is nearly useless. It’s also wrong, since this function could easily raise KeyboardInterrupt, which isn’t a subclass of Exception. To be correct, you would have to annotate this as being able to raise BaseException, which is completely useless - every function can raise some subclass of BaseException.
You have gained zero information and only added unnecessary boilerplate to your functions.
Just make sure you carefully read the ideas proposed in similar threads (I think at least two other were created in the last six months) and be ready to drop it if you find that your idea is essentially the same
Okay. I see no point in responding to the thesis described in that article, because Aaron Moore’s idea differed from mine at least in his desire to annotate to make it easier to find errors.
I will clarify my idea.
As you know, there is no syntax for describing errors. That doesn’t make any problem. Error annotation can just be good syntax for libraries. Here is a very simple example for a pseudo-library:
from pseudoapi import APIRouter, HTTPError404, HTTPError500
from random import randint
from repositories import test_repo, SmthException
from typing import Raises
router = APIRouter()
async def text(tid: str) -> Raises[HTTPError404, HTTPError500] & dict:
if randint(0, 1) == 0:
raise HTTPError500("Something went wrong")
return await test_repo.get_test(tid)
except SmthException as e:
raise HTTPError404("Test not found")
Another use case for this is self-documenting code. Yes, this is much more intuitive than docstring.
Sounds ridiculous, in that case, you can just turn off the PC, I assure you, that does not wait even super safe Rust )
If you look at it from the point of view of error handling and making Python more safe – the annotation idea is not the best. But as a handy tool, why not?
“Why not” is not a reason to add a feature to a language. The correct question is “Why?”. What is the advantage of this? We don’t do things just because there’s no reason not to; there needs to be a solid reason for doing it.
And every reason given so far has been answered. So you’ll need to find a new and compelling reason.
If you’re interested in doing this purely for documentation, not for type checking, you may be able to use typing.Annotated, something like Annotated[str, Raises(IOError)]. This would be ignored by static type checkers, but could still be useful for readers of the code.