3 ms·
I think the point is that your specific cases: > Many programmers in many situations would be perfectly happy to catch "failure to open a file" and "failure to
by chollida1 15y ago
I think the point is that your specific cases:
> Many programmers in many situations would be perfectly happy to catch "failure to open a file" and "failure to open a database connection" and "failure to connect to a network host" with one simple handler that logs the failure and either aborts, retries or ignores.
aren't exception appropriate a according to a certain portion of developers. The reason they aren't exception appropriate is that you should expect these things to happen from time to time, ie they are not exceptional.
using exceptions to handle them is part of the problem Go attempts to solve by having multiple return values.
- Dylan16807 15y agoAs far as I can tell either your point is a circular argument or it's an English-language nomenclature complaint fixable by s/exception/fooglewoo/. Either way it doesn't address the real argument, about where it is appropriate to use try and catch. What is inherently better about multiple return values at every level, compared to semi-centralized catch blocks?
- msbarnett 15y agoIt's not really an objection to terminology. "Fooglewoo" handlers would still exist outside the normal flow of control while handling things that many people would consider routine. Burying that kind of every-day, expected-circumstance logic in a side channel is, at least in some developers opinions, detrimental to the readability and understandability of a program.
- chollida1 15y agoI'm sorry, I can't really parse your argument. My point was that there is a school of htought that exceptions should only be used in "exceptional" circumstances. The examples given were not exceptional in that a programmer should expect those types of errors during the normal execution of their program. Therefor exceptions aren't the solution to those types of errors. Does that make more sense to you?
- Dylan16807 15y agoBut using that school of thought to support that school of thought isn't an argument, it's a circle. PaulHoule is explaining why he likes a specific mechanism compared to another, and you are only replying with the previously-established fact that there exists a disagreement here, not a counterargument.
- chollida1 15y agoI get what your saying, I just disagree. And I think alot of people take my point of view as evidenced by the votes my initial post received. No worries, thanks for the point of view:)