4 ms·

Ok, I'll bite. Disclaimer: I'm not a software engineer, FPGA engineer by training. The use model I have in my mind is that my functions all work 99.999% of the

Ok, I'll bite. Disclaimer: I'm not a software engineer, FPGA engineer by training. The use model I have in my mind is that my functions all work 99.999% of the time, but occasionally something happens where basically I want to throw up, I want the whole thing to collapse. Exceptions are great for me. I'm in an industry where "stop" is an okay solution in the rare occasion something goes wrong. So what's the alternative? I have to overload my return values annd then put in a load of special cases to propogate or return the exceptional cases. I am aware there are functional languages that have other ways of dealing with this, or languages with things like optional values etc. But fundamentaly I like the idea that there's just a mechanism to just collapse, and collapse in a way that is traceable. Having said that, my experience essentially does not involve catching exceptions, to me that's what is almost unthinkable (read: probably a bad hack). I guess my use case is not performance but separateing normal code function from catastrophic errors. Could you explain, do you think this is a fundamental mistake in the way I'm approaching this?

randyrand 5y ago
> I have to overload my return values annd then put in a load of special cases to propogate or return the exceptional cases. Yes + syntactic sugar. Propagating an error up can and should be a single character of code. > collapse in a way that is traceable. Zig supports "error traces" (note, not stack traces) by default, since they have a single common way of reporting errors and a smart compiler. > I like the idea that there's just a mechanism to just collapse, Go uses Panic + Recover.
kinjba11 5y ago
> my experience essentially does not involve catching exceptions Which is part of the problem. If you're not catching the exception, you don't need exceptions. You just need a way to log stuff, such as a trace, and exit the program. New languages such as Rust and Go encourage this explicitly - that is, use the ordained error path in the return value for expected errors, and only panic for catastrophic errors (or use panic in hotpath where return overhead has unacceptable performance impact and errors are super rare). http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p070... > Programs bugs are not recoverable run-time errors and so should not be reported as exceptions or error codes. — We must express preconditions, but using a tool other than exceptions... migrate std:: away from throwing exceptions for precondition violations.
- ncmncm 5y ago
  When you are writing a library, you don't know what the program that calls you might have set up to handle failures, but you know exactly how to get to it: throw, and you are there, and it is now for the caller to decide what to do, thus not your problem. A library that exits has stolen control away from its rightful owner. Very few languages are as finely tuned to the needs of libraries and users of libraries as C++. Exceptions are an essential part of that compact. Failing to abide by it makes your library a bad citizen.
  - deleted 5y ago
    [deleted]
  - kinjba11 5y ago
    In any case, these arguments have been hashed many times. I always recommend reading Joe Duffy's post on errors for the curious. http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/
- Too 5y ago
  ”If you're not catching the exception, you don't need” Exactly. But the upstream caller of your function might need it. And that’s the beauty of it. If I don’t know how to handle a particular error in one context, I can just leave it and let it propagate upwards. For example downloadFile()->parseHttpResponseStrean()->readSocket() If readSocket throws a timeoutError I don’t need every http library to explicitly deal with it. What can they even do about it, apart from retrying? The application level code calling the downloadFile function is still free to catch the error and gracefully show an error to the user or use a default file from disk if they please.
  - kinjba11 5y ago
    Instead of catching an error why not just return it. Then it's obvious to anyone reading that an error can happen there. auto fileOrError = downloadFile(); if (fileOrError is error) {...}

randyrand 5y ago

> I have to overload my return values annd then put in a load of special cases to propogate or return the exceptional cases. Yes + syntactic sugar. Propagating an error up can and should be a single character of code. > collapse in a way that is traceable. Zig supports "error traces" (note, not stack traces) by default, since they have a single common way of reporting errors and a smart compiler. > I like the idea that there's just a mechanism to just collapse, Go uses Panic + Recover.

kinjba11 5y ago

> my experience essentially does not involve catching exceptions Which is part of the problem. If you're not catching the exception, you don't need exceptions. You just need a way to log stuff, such as a trace, and exit the program. New languages such as Rust and Go encourage this explicitly - that is, use the ordained error path in the return value for expected errors, and only panic for catastrophic errors (or use panic in hotpath where return overhead has unacceptable performance impact and errors are super rare). http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p070... > Programs bugs are not recoverable run-time errors and so should not be reported as exceptions or error codes. — We must express preconditions, but using a tool other than exceptions... migrate std:: away from throwing exceptions for precondition violations.

ncmncm 5y ago
When you are writing a library, you don't know what the program that calls you might have set up to handle failures, but you know exactly how to get to it: throw, and you are there, and it is now for the caller to decide what to do, thus not your problem. A library that exits has stolen control away from its rightful owner. Very few languages are as finely tuned to the needs of libraries and users of libraries as C++. Exceptions are an essential part of that compact. Failing to abide by it makes your library a bad citizen.
- deleted 5y ago
  [deleted]
- kinjba11 5y ago
  In any case, these arguments have been hashed many times. I always recommend reading Joe Duffy's post on errors for the curious. http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/
Too 5y ago
”If you're not catching the exception, you don't need” Exactly. But the upstream caller of your function might need it. And that’s the beauty of it. If I don’t know how to handle a particular error in one context, I can just leave it and let it propagate upwards. For example downloadFile()->parseHttpResponseStrean()->readSocket() If readSocket throws a timeoutError I don’t need every http library to explicitly deal with it. What can they even do about it, apart from retrying? The application level code calling the downloadFile function is still free to catch the error and gracefully show an error to the user or use a default file from disk if they please.
- kinjba11 5y ago
  Instead of catching an error why not just return it. Then it's obvious to anyone reading that an error can happen there. auto fileOrError = downloadFile(); if (fileOrError is error) {...}