61–70 of 93 posts
There are dumb people.
I've seen dumb things.
My exceptions, however, are excellent. I'm tried of talking to dishonest people. It gets really old. It's funny -- at osdev, there's a guy named RDOS. All his answers support his position -- it's really pathetic. Just walk away.
Earlier quoted context omitted.
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
You forgot to mention one of the main criticism to use exceptions for errors: the processor penalty. Related discussions: - http://stackoverflow.com/questions/8805238/run-time-penalty-... - http://stackoverflow.com/questions/299068/how-slow-are-java-...
Earlier quoted context omitted.
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
You forgot to mention one of the main criticism to use exceptions for errors: the processor penalty. Related discussions: - http://stackoverflow.com/questions/8805238/run-time-penalty-... - http://stackoverflow.com/questions/299068/how-slow-are-java-...
As with much of the exceptions debate, it’s important not to over-generalise here.
For example, if you’re writing in a compiled language like C++ and your compiler uses a table-driven implementation for the exception mechanism (as most modern ones did, the last time I checked) then there isn’t necessarily any direct runtime overhead at all when no exception is thrown. In fact, the non-exceptional code path can even run a little faster than equivalent code with manual error handling via return codes, if conditional logic for propagating error codes can be omitted at all the intermediate levels between the one(s) where exceptions are thrown and the one(s) where they are caught.
On the other hand, the possibility of an exception being thrown might interfere with some optimisations. Also, the jump tables can be huge: I once saw the compiled output for a moderately large code base drop in size by 1/3 just from compiling it with exceptions disabled.
In short, there are a lot of factors at play, but anyone who parrots the line that using exceptions always slows things down has never spent much time looking at what actually happens with real compilers. And of course, this is only in one type of compiled language, which doesn’t necessarily imply anything about the performance characteristics of other languages (which vary widely).
You can make methods easily return multiple values in C# with Tuples. They are very handy.
Earlier quoted context omitted.
I have to say, I much prefer people referring to it as Golang, otherwise it is impossible to search for.
this is honestly the most annoying thing about go for me. Really hard to do a quick google search for an answer to something!
Earlier quoted context omitted.
Functions should be scoped appropriately so that they only deal with one thing at a time. A function that checks for network connectivity isn't going to be checking for missing rows. Those are different problems, and should be handled by different functions. Using your example, we have a function that queries a database. It will be given a valid database connection, and return the result of the query. There is no "va…
You can't just assume that a valid database connection will remain valid the entire time you're using it. The network or server is free to go down at any time. In practice, this rarely happens, it's an exceptional condition. Exceptions are the best way to model these kind of errors.
Point is: the function that deals with database response should never be responsible for dealing with database connection errors.
Earlier quoted context omitted.
this is honestly the most annoying thing about go for me. Really hard to do a quick google search for an answer to something!
Try "Django" with that new "Django Unchained" movie ;-)
Earlier quoted context omitted.
I have to say, I much prefer people referring to it as Golang, otherwise it is impossible to search for.
this is honestly the most annoying thing about go for me. Really hard to do a quick google search for an answer to something!
Earlier quoted context omitted.
You forgot to mention one of the main criticism to use exceptions for errors: the processor penalty. Related discussions: - http://stackoverflow.com/questions/8805238/run-time-penalty-... - http://stackoverflow.com/questions/299068/how-slow-are-java-...
You forgot to mention one of the main criticism to use exceptions for errors: the processor penalty. As with much of the exceptions debate, it’s important not to over-generalise here. For example, if you’re writing in a compiled language like C++ and your compiler uses a table-driven implementation for the exception mechanism (as most modern ones did, the last time I checked) then there isn’t necessarily any direct r…
This probably extended to things like the xbox as well.
Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…