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

it really depends on what the empty string means in this context (and it's not specific to Error Values or Exceptions). if the empty string means error (the function not being able to return a valid value), then an exception is the right thing. for a different function an empty string is perfectly valid. a good question of conscience to ask yourself when you can't decide, is whether you are returning a special value for a specific a specific caller or whether the function needs a better "name" (avoid magic values). empty string is a bit of a tricky one admittedly, and you should probably consider NULL instead if there is no value. my preferred example is the empty list. i hate it when people give an error (regardless of whether it's an Exception or Error Value), instead of an empty list to indicate no results (let me decide whether an empty list constitutes an error)
2
unless it's a Functional language like F#, which also contains Exceptions that will skip your Error Value handling
2
@notuxnobux checked exceptions in Java were actually a very poor design decision. it's well established
2
this is a bad take from ThePrimeagen, as he clearly has no experience with Exceptions. but, you should use whatever Error Handling is enforced by the language. Exceptions most languages don't force you to check returned Error Values (so you can unfortunately forget), which means it's better to use Exceptions in most cases. what ThePrimeagen is also misunderstanding is that catching Exceptions is hardly ever needed on every level of the call stack, because the cleaning up can usually be done in a "finally" clause instead of a catch clause. i think that the performance penalty that comes with Exceptions, is really the only consideration in some special circumstances Error Values in other languages where the compiler forces you to check for returned Error Values, there you can get away with Error Values. unless the language also contains Exceptions like F#, and your checking will be skipped, in which case you may as well only use Exceptions i'm tired of this old and dumb discussion.
2
@gagagero you hit the nail on the head. both ThePrimeagen and the article's author seem confused
2
@shacham6 you mistakenly assume that all Exceptions have to be caught, and that they have have to be caught as soon as possible. heck, if you have an umbrella for the whole program, then you should consider not even having that and just letting the program crash and let the system record the exception
2
@dezyhe you can include a custom human error when you throw an exception. there is no difference there. but you can't even see any of the top frames with error values by default
2
that's meaningless
1
@justgame5508 what are exceptional circumstances for you? it just seems like a common phrase that people blindly repeat
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. my claim is that errors, are not recoverable in most contexts. so the caller doesn't have to do anything to let the Exception propagate by default. this saves a lot of (forgotten) error handling logic and magic return values (potential bugs) throughout the call stack, and that is the big advantage. also dealing with invalid user input in a form is a bit of a special case because it often involves gathering all the errors to show to the user and not immediately ending the control flow. but if i don't yet want to end the control flow when encountering an error then i simply won't throw an Exception, until i've gathered the errors. personally, i usually only use Exceptions for the individual errors when the code is used in other place that need that. i think it's the job of languages and frameworks to make this less awkward and more performant. unfortunately a lot of times languages and frameworks make the decision for you, that you should be using Error Values instead of Exceptions. but that's a separate matter.
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. my claim is that errors, are not recoverable in most contexts. (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. my claim is that errors, are not recoverable in most contexts. (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. my claim is that errors are not recoverable, in most contexts. (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. i claim that errors are not recoverable, in most contexts. (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. i claim that errors are not recoverable (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. i claim that errors (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. i claim (editing. don't reply yet...)
1
@justgame5508 @justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. i (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. my opinion (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. in my opinion (editing. don't reply yet...)
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. my claim is that errors, are not recoverable in most contexts. so the caller doesn't have to do anything to let the Exception propagate by default. this saves a lot of (forgotten) error handling logic and magic return values (potential bugs) throughout the call stack, and that is the big advantage. also dealing with invalid user input in a form is a bit of a special case because it often involves gathering all the errors to show to the user and not immediately ending the control flow. but if i don't yet want to end the control flow when encountering an error then i simply won't throw an Exception, until i've gathered the errors. personally, i usually only use Exceptions for the individual errors when the code is used in other place that need that. i think it's the job of languages and frameworks to make this less awkward and more performant. unfortunately a lot of times languages and frameworks make the decision for you, that you should be using Error Values instead of Exceptions. but that's a separate matter.
1
@justgame5508 yes, there are typical circumstances that a program can't or shouldn't recover from, but this is ultimately dependent on the program. it's even dependent on the calling function. yes, invalid user input is recoverable when you use it in a form because the user can simply try again, but invalid user input in an unattended background job is usually not recoverable. failing to read from IO due to insufficient privileges is recoverable, in the rare case that you can read from other IO. as you said, it depends on the context. the caller is the context. this becomes very obvious when writing a library. for me Exceptions are simply an easy way to end the control flow, when i can't fulfill what the caller asked. the caller can decide whether it wants to recover, by catching the Exception. (continued in next comment...)
1
@justgame5508 my claim is that errors are not recoverable, in most contexts. so the caller doesn't have to do anything to let the Exception propagate by default. this saves a lot of (forgotten) error handling logic and magic return values (potential bugs) throughout the call stack, and that is the big advantage. also dealing with invalid user input in a form is a bit of a special case because it often involves gathering all the errors to show to the user and not immediately ending the control flow. but if i don't yet want to end the control flow when encountering an error then i simply won't throw an Exception, until i've gathered the errors. personally, i usually only use Exceptions for the individual errors when the code is used in other place that need that. i think it's the job of languages and frameworks to make this less awkward and more performant. unfortunately a lot of times languages and frameworks make the decision for you, that you should be using Error Values instead of Exceptions. but that's a separate matter.
1
but it's not really about preferences. it's about using what is enforced by the language. being forced to check Error Values usually isn't enforced by the language, in which case you can forget. and an action that continues despite an error (writer forgot to check an Error Value), can typically do more damage than an action that stops (writer forgot to catch an Exception). relying on Error Values is only really safe when the writer is forced to handle handle all of them, and the languages does not contain Exceptions
1
@McZsh exactly. well said
1
@thingsiplay i think you are missing the point. chances are that you won't handle: - the database not being accessible differently, - from not having the correct credentials to the database. it doesn't matter whether you view this from Rusts perspective, because you chose the language
1
@thingsiplay are you suggesting that handling different errors in the same way, is the same as not handling them?
1
@thingsiplay also. being forced to add a handler (which could potentially do nothing), is not the same as actually handling an error
1
@thingsiplay i know. care to respond to my other comment?
1
@Musikur input forms are a bit of a special case. because you normally want to collect all errors to show to the user, instead of stopping after the first field. this typically extends to the back-end, so that it can be used in an input form (if you have a separate front-end and back-end). i'm not disagreeing with you, as i could see this work with Exceptions or Error Values. this is just a tangent
1