General statistics
List of Youtube channels
Youtube commenter search
Distinguished comments
About

ThePrimeTime
comments

Comments by "" (@diadetediotedio6918) on "Why I Prefer Exceptions To Errors" video.

1. The stacktrace is not always necessary, literally, when you describe your errors as strong types modeled in your application. LITERALLY, they are not needed. And MANY times the stack traces are devoid of any meaning (for example, when you are dealing with an event loop). 2. This is not something exclusive for exceptions, you can pretty much have stack traces in errors as values as a default for a language (and you can do it in many languages with libs), so it do not make to say this is a point in defense of exceptions.
33
@Zuftware You can absolutely have both if your language is structured for it, exceptions were made to be <exceptional>, people made them the default in languages that have them because options were not provided for the other case.
10
I like the mixed approach, my problem is more when the language leads you into dealing with your errors as exceptions first instead of representing them as simple errors (like JS, Java or C#).
6
@alexgoncharov6430 > The main reason for that is developers didn’t consider all possible scenarios of what can go wrong You are just misunderstanding the crucial difference between what an error is and what a crash is. You only want to "consider all possible scenarios of what can go wrong" if you are dealing with crashes. When you deal with errors you are dealing with a thing that is specific for the "domains" you are dealing with in your application.
5
@s3rit661 It is almost literally <always> a "programmer's fault", you are really saying nothing at all with this. The tool should make it harder to the programmer to make mistakes, this is one of the responsibilities of the tool.
4
@vinterskugge907 "much more code is required" and? Your point is seriously that all error handling should be made to the point of one single catch location?
4
@depafrom5277 "not that we would ever implement it like this" then your comment is absolutely pointless. You can also just .unwrap() all your errors as values or just pass them around without ever checking them.
4
@yyny0 " `throw` does unwind the stack more efficiently than `return` does" Why exactly?
4
@vinterskugge907 > Remember from the original post: "when developing stateless backend applications". This really don't matter to me. I do stateless backends and I literally use results as errors, and I don't agree with him, and I'm arguing with you about it. You are saying this as if the operations you make should never fallback or never have side effects when they fail, and this is a very specific type of system you are describing while the "stateless backend" claim was very broad.
3
@depafrom5277 What is the point mister "this is how it is better, but of course we would never implement it like this"?
3
The first thing you should ask is: What does zig have to do with prime's arguments? Is Zig the unique language that deals with errors without exceptions?
3
This is a knife with two blades, sometimes you just don't need the stacktrace and just want to represent a simple error, and exceptions are overkill for that. But any language with errors as values can solve the stacktrace thing, it is not a blocker or something that makes exceptions the unique solution for this.
3
And you just need to use like one of the 2 unique mainstream languages that adopted that, one of them is not entirely happy with it and the other had its spiritual successor (Kotlin) ditching them entirely. I think checked exceptions solve the problem, but they are much more annoying to deal with.
3
@alexgoncharov6430 You just reafirmed your own previous statement, thou understand this is not how to respond to someone, right?
3
@isodoubIet It does not "disallows error-neutral functions", what are you talking about? Plus, function coloring is required whenever you <use any type system at all>, and it is not a problem because the Rust type system can infer the types for you, so most of the time this is not a concern. Otherwise you need to make an argument of why function coloring is necessarily a bad thing.
2
@isodoubIet > Of course it's a bad thing. It inhibits code reuse It really depends on what you are calling "code reuse", I'd need to disagree with you on this one if you don't show some concrete real world examples of this. > loosens the system modeling as you're now encouraged to report and handle errors even if there's no possibility of such This is a sign of bad API design and not a problem with having errors as values. If you are returning a "maybe error" from a function then it <maybe> an error, it is a clear decision to make. > increases coupling between unrelated parts of the code I mean, not really, you can always flatten errors or discard them easily in an EAV model. > and can force refactorings of arbitrarily large amounts of code if even one call site is modified. Again, this is true for any kind of function coloring, including <type systems> and <checked exceptions> (like Java has). A good designed code should be resilient to this kind of problem most of the time. > You can say "this is a tradeoff I'm willing to make". That is fine. You cannot say this isn't a bad thing. I absolutely can say it is not a bad thing. It is not a bad thing. See? I don't think function coloring is necessarily bad, thus I would not agree with you upfront this is a bad thing. I think being explicit about what a code does and the side effects that it can trigger is a good thing, an annoying thing sometimes I can concede, but I cannot call it a "bad thing" on itself, only the parts that are actually annoying (and the same goes for when you don't have this kind of coloring and then it blows up in your head because of it, it is a "bad thing", not the lack of coloring itself).
2
stysner4580 Bad system design.
2
@cl8lf1wm8b Oh, I like this argument. I'll tell you a secret then: if you don't write the program you will write the smallest amount of code is possible (which is 0), then you will not have "more errors, more effort to support". Dealing with errors, on the other hand, <prevent more errors> and <makes the need to do constant support lower>, not higher. It is not <all the code> you write more that makes you more prone to bugs that matter, if you use this like that it is just a silly catchphrase without meaning.
2
> The beginner level way to handle OOM issues is to pre-allocate any data structure you need to resolve OOM This is not the "beginner level way", it is the way most of the managed languages do it.
2
@isodoubIet They are, and your response don't make sense, what the heck "skill issues" have to do with exceptions being functionally equivalent to non-local gotos?
2
@isodoubIet Okay. Backup your claim, explain to me how exceptions work in C++ (a language used in the article as an example of having exceptions and doing better code with them).
2
@defeqel6537 "it is easy to abuse" is such a blank statement lol
2
Yet, C++ is implementing errors as values. I don't think they are much convinced with that.
1
@isodoubIet ["You can't have a function that will never fail if none of the functions it transitively calls ever fails, or which will fail otherwise."] What the heck are you saying? First. Define "error-neutral functions", then we will proceed. It seems to me you are making a salad here.
1
@isodoubIet You have a problem in understanding, I see. My claim was: ["Plus, function coloring is required whenever you <use any type system at all>, and it is not a problem because the Rust type system can infer the types for you, so most of the time this is not a concern."], learn to read things entirely instead of nitpicking parts. Function coloring is a defacto thing for any language that has types, including C++. It do not mean that the errors will be part of that function coloring, it just means it <exists> in the language when you are using it, if the point is that <function coloring = bad> this should be a problem for you. > Also nonsense. If you change the error handling strategy of some function deep in the call stack, you'll end up needing to refactor an arbitrary large amount of code. Just like if you suddenly need your exceptions to matter more locally you need to refactor an arbitrarily large amount of code to catch them in every possible single call site. It also matters more for me if you are designing your systems so badly this is often necessary, but anyways. And if you use Java for example exceptions can be <function coloring> as they need to be marked in the header of functions (and if you skip them you need to mark your function or convert it to an uncked one). This is just a terrible point in defense of exceptions.
1
@isodoubIet Oh, now I got what you mean. With "error-neutral functions" you are talking about "functions that ignore the possible errors they can throw entirely". Yeah, in this case you are right, Rust can't have this kind of 'error neutral function' <if> you are the prefered way of dealing with errors in the language. But from this fact to this being a bad thing is completely another question.
1
@isodoubIet No, you seriously have. I justified my reasoning and you did not replied to it. > Nope, I will have to refactor zero code, because the errors are not tracked in the type system and are already handled. Again, problems with understanding. Read again what I said: > Just like if you suddenly need your exceptions to matter more locally you need to refactor an arbitrarily large amount of cod Exceptions ARE tracked by the type system, they literally are catched BY TYPE, if you <need your exceptions to matter more ---locally---> you will need to go on every single place and modify the code if you change your exception types or remove the exceptions. You also completely ignored my point on exceptions not being contrary to function coloring when I mentioned Java and it's checked exceptions.
1
From a Java perspective, checked exceptions are avoidable.
1
@s3rit661 I don't think this is "the same argument". 1. Checked exceptions are, in fact, optional in Java, you can quite literally ignore them and turn them into unchecked ones (and many of those that are actually important, like NPEs, are ignorable). Kotlin is a language that runs in JVM and literally ditcched checked exceptions, if this was a concept working in Java I don't think they would go to this route. 2. The Rust thing is about <memory safety>, not about "ensuring you never make mistakes", memory safety is a no-problem in languages like Java and Rust ensures you don't make mistakes with memory with the borrow checker, which is another thing than error checking mechanism. The guarantees you have there are extremely specific as well, it is not "it is impossible to make mistakes", it is "if you use the type-system, if you check your unsafe code with tools like MIRI and do proper tests on it, if you don't circumvent borrow checker rules, them you are in the possible program space where it should be impossible for you to create a memory safety issue in your program". The error as values are a bonus and they work pretty well with this system.
1
37:30 This is only partially true as well, you can always deal with the errors in the cold paths directly after getting the values and <then> consuming it in hot paths. Exceptions are not magical either, if you are calling exception-prone code in a hot path you are still paying a cost to assert or check if an exception could happen + the cost of dealing with that exception if it does happen.
1
@goldsucc6068 "Most of the backend code is Java" From where you got this statistics? If I would guess PHP would be the "most backend code", not Java by FAR. But I'm willing to read your data.
1
@bonnassem ? Stack unwinding works by literally going up the call stack and checking if anyone is catching the exceptions, what are you talking about?
1
@bonnassem ["Stack unwinding does only the required part, i.e. destroy the things you need to destroy. It only jumps around itself and presumably has much less ret instructions."]~ This is more reasonable. But then it should be pointed that this is only a problem if this kind of unwinding is what your application wants, and in this case most languages and even Rust have a mechanism that can unwind the stack in a similar fashion.
1
@yyny0 This is true, yes, but arguably the overhead of doing these checks is minimal if you are constraining yourself to when they actually need to happen. And while it is true that you cannot circumvent this problem when having errors as values (unless you are willing to deal with pointer manipulation, in which case you can pretty much skip the check, but nobody does this), you can also not avoid this if you are trying to make a locality enforced error handling with exceptions (as you will need to have the try-catch everywhere in your code, and you will pay the cost of having the extra code in your function for dealing with the exception just like in the eav case). It is also arguable if the cost of checking the stack frames that <do> need the cleanup would not outweight the benefits in performance you are claiming it has, but I did not measured this to say, maybe I'm not considering even more factors here like the non-locality of code causing a problem with the predictors in the CPU (or the whole context switching problem that is a pretty massive hit for CPUs, althought I cannot say the cost ammortizes when you don't have many exceptions). Apparently @bonassem had tested them tho.
1
@yyny0 (my message apparently got swizzled, so sending it again) This is true, yes, but arguably the overhead of doing these checks is minimal if you are constraining yourself to when they actually need to happen. And while it is true that you cannot circumvent this problem when having errors as values (unless you are willing to deal with pointer manipulation, in which case you can pretty much skip the check, but nobody does this), you can also not avoid this if you are trying to make a locality enforced error handling with exceptions (as you will need to have the try-catch everywhere in your code, and you will pay the cost of having the extra code in your function for dealing with the exception just like in the eav case). It is also arguable if the cost of checking the stack frames that <do> need the cleanup would not outweight the benefits in performance you are claiming it has, but I did not measured this to say, maybe I'm not considering even more factors here like the non-locality of code causing a problem with the predictors in the CPU (or the whole context switching problem that is a pretty massive hit for CPUs, althought I cannot say the cost ammortizes when you don't have many exceptions).
1
The opposite is possible as well. But I don't care much about this.
1
44:00 The only reason Java can "handle" OOMs (as well with C#) is that OOM exceptions are already preallocated when you execute code. I feel this is just a weird thing to expect from a language that should not have an entire complex runtime by default and that can be handled by manually creating one if you need. But of course, try_new would be an interesting thing when we can predict the memory allocation can not work (but I don't think this will imply in preventing OOMs either, only a specific subset).
1
@s3rit661 Partially only.
1
What I find very funny is that people that defend exceptions blindly are usually the same ones that say you should not use global-level gotos in your codebase, when they are functionally the same thing (and can even be used for the same purposes many times). Obviously this is a funny thing and I'm not saying all models of exceptions are problematic like this, but most of the mainstream languages are.
1
@isodoubIet My claim is that throwing exceptions is functionally equivalent to a goto. <Functionally> meaning it functions in a similar fashion (i.e. you are jumping from an arbitrary place in your code to a predefined another place, not only it functions but exceptions are also implemented that way in C++). You cannot also exactly "goto arbirary random places in the code" with non-local gotos (in most languages that have it, at least), you need to add a mark to those places firstly. I used specifically the words "(and can even be used for the same purposes many times)" in my argument, so do you want me to show it? First: ``` #include <iostream> #include <csetjmp> std::jmp_buf jumpBuffer; void second_fn() { std::cout << "in :: [second_fn]" << std::endl; std::longjmp(jumpBuffer, 2); std::cout << "will not happen" << std::endl; } void first_fn() { std::cout << "in :: [first_fn]" << std::endl; second_fn(); std::cout << "will not happen" << std::endl; } int main() { std::cout << "in :: [main]" << std::endl; int ret = setjmp(jumpBuffer); if (ret == 0) { std::cout << "calling :: [first_fn]" << std::endl; first_fn(); } else if (ret == 2) { std::cout << "in :: [main] from -> second_fn with : longjmp" << std::endl; } std::cout << "end" << std::endl; return 0; } ``` Second: ``` #include <iostream> #include <string>; void second_fn() { std::cout << "in :: [second_fn]" << std::endl; throw "ops"; std::cout << "will not happen" << std::endl; } void first_fn() { std::cout << "in :: [first_fn]" << std::endl; second_fn(); std::cout << "will not happen" << std::endl; } int main() { std::cout << "in :: [main]" << std::endl; try { std::cout << "calling :: [first_fn]" << std::endl; first_fn(); } catch(const char*) { std::cout << "in :: [main] from -> second_fn with : exceptions" << std::endl; } std::cout << "end" << std::endl; return 0; } ``` The results: ``` A -> in :: [main] calling :: [first_fn] in :: [first_fn] in :: [second_fn] in :: [main] from -> second_fn with : longjmp end B -> in :: [main] calling :: [first_fn] in :: [first_fn] in :: [second_fn] in :: [main] from -> second_fn with : exceptions end ```
1
stysner4580 Code should be reentrant when you use these languages.
1
@slr150 This is not a reason they are "better", this can be easily achieved with errors as values. And by the way, exceptions stack traces are many times completely useless, for example when you deal with event loops.
1
@yyny0 What are you talking about man? LITERALLY they can, it was ALREADY ACHIEVED by many crates in the rust ecosystem for example. I'm going crazy or are you talking about something very specific that makes it <impossible> to capture a stacktrace from a program in a given point in time and pop it up? If you can prove your statement maybe I will see your point with better eyes. I also don't understand what do you mean by this: ["if a library function returns an error value, those stack frames have already returned. Many such cases!"], if you can clarify it.
1
@yyny0 > [ Crates like anyhow? Most libraries do not use that crate, and in fact, the recommendation from anyhow author is to NOT use them for library code. This means that the errors returned from those libraries do NOT have stacktraces, and NO way to recover them. ] Oh, now I get it. You want to have <libraries stack trace>, not <stacktrace in general>. Well, first: It is indeed possible to get the stacktrace of a program from errors as values, so your statement was wrong. You can move the discussion to the fact that this is more of a problem with libraries, and I would agree, it is a pain in this specific case, but you <cannot say> it <can't be done>, it can. Now, you said this is a problem for <errors as values>, but this is more of a problem for <Rust>. A language crafted around errors as values that have stacktraces opt-in at the consumer level of libraries would literally solve this problem and then your point would be much less interesting, so it is kinda fragile to criticize errors as values in this regard based on the design decisions of Rust. > [We've had several "fun" multi-hour debug sessions because of that.] So you are using Rust? What, you just said your service has many exceptions and all in the other comment, or are you talking about a different project or something like that? Also, can you explain me exactly how the lack of stacktraces in specific libraries costed you "several 'fun' multi-hour debug sessions"? I literally never experienced a "multi-hour debug session" because of something like that, and I work on a heck lot of projects, so a more concrete explanation will be good for the mutual understanding part of this discussion. > [Also, those crates are opt-in, and even some of our own code does not use anyhow, because it makes error handling an absolute pain compared to a plain `enum`s.] It makes? What??? It literally was made <to make using errors less painful>, given the purpose of this library, why do you find it <an absolute pain> compared to plain enums? You also don't need to use anyhow, see, you can literally easily capture stacktraces in your application by using std::backtrace::capture or force_capture, in the Rust page they even say it is a pretty easy way of gathering the causal chain that lead to the errors, you literally need to implement like 30 lines of code and use it in your whole application if you want to.
1
> AFAIK, exceptions turn into a "goto" statement, basically. If you are doing million operations and check an error status after each one, that is a huge CPU overhead. Except you don't need to do it on "million of operations", you just need to architect you code in a non obviously terrible way and make the hot paths not checking it. + you are still doing a million of error check operations with exceptions, the difference is that the ones throwing are doing it and not the ones catching, and that you are paying a million times of extra cost when an error actually happens.
1
@yyny0 "the cost of an error is irrelevant, it should never happen and (...)" > this is something I will need to disagree very hardly. Do you have any statistics to back up your claim that it is irrelevant? + Why exactly an error, a perfectly valid representation of a specific part of a system in a given time, <should> never happen and what is the factr that makes it "gind my entire program to a halt anyway"?
1
@yyny0 > [An error is incorrect by definition, it is NOT a valid representation of your system, in fact, the whole point of returning an error value is to describe invalid program state.] What I said: ["a perfectly valid representation of a specific part of a system in a given time"], an error IS, in fact, a perfectly <valid> (in a formal sense, and sometimes in business rules) <representation> of a <specific part> of a system in a given time. When you do a login and you type the password wrong, the InvalidPassword <IS>, in fact, a perfectly reasonable and valid <representation> of state in your system (as it should be, it should not panic your software, just exhibit a simple message to the user so he can type the correct password). When you call a method to write to a file, and the file do not exist, receiving a monad where the error is represented as a possibility <IS>, indeed, a perfectly valid way of representing your program state. I just don't know why are you saying this. An error could be defined as a "undesired state given a specific goal intended in a closed system", but not necessarily as an "invalid state" if it is conceived as to be a part of the representation of your possible states. dot. Proceeding. > [As for statistics: our production product has ~20k `throw`s across all our (vendored) dependencies (of which ~2k in our own code), and only 130 places where we catch them. Most of those places also immediately retry or restart the entire task.(...)Additionally, 99.9998% of those tasks in the last hour did not return an error, so even if the cost of throwing a single error was 1000x the cost of running an entire task (which it is not), it would still be irrelevant.] You said "it should never happen", and then you showed me your personal data and said it happens 20k times, I would say this is a damn high number to say it "should never happen". Also, you did not give me any timeframe, not a comparison between different services, giving me one personal example is just anedoctal example. How exactly I'm supposed to work with this and say there are not very statistically representative systems that <do> have an impact with throwing exceptions for everything? This is a pretty specific response. > [I would consider that "grinding to a halt".] You consider restarting a program immediately after an error the same as "grinding to a halt"?
1
@comradepeter87 Yes? This is why I said in my first comment that both approaches can be mixed together.
1
My problem is more when the languages make exceptions are the default way of doing errors.
1
@amotriuc This is false. If you use result errors and are dealing with them manually every single time you are "doing result error handling incorrectly". With results you typically do monadic expressions, and when you can't you just get the values once and then only go back to checking if's when you call another tainted piece of code again.
1
@theairaccumulator7144 > nested ifs are evil and I hate go because of it > uses global level goto abstraction all the time (exceptions)
1