4 ms·

to understand what I said, you have to solve the Error Handling Challenge, in your favorite programming language https://rm4n0s.github.io/posts/3-error-handling

to understand what I said, you have to solve the Error Handling Challenge, in your favorite programming language https://rm4n0s.github.io/posts/3-error-handling-challenge/ https://rm4n0s.github.io/posts/3-error-handling-challenge/ When you try to implement it, then everything on what I said will make sense to you. Also, we don't need log systems when there is a programming language like Odin to parse stack traces with type checking (not just string like you gave me as an example from Java). In microservices you are the error handlers. For example, if in the logs you see a stack trace, then you will go to the code and fix the error. In Odin I don't need to go in that trouble, because ALL the stack traces can be handled. There will be no undefined behavior in software or unexpected input that caused an unexpected stack trace, so there is no reason to have logs.

tharkun__ 2y ago
I looked at that and I find it pretty funny. As in, why would I ever build error handling that cares about the specific call stack to handle the error? That makes no sense to me. I'll show you why. Let's say you have the call stack as this (from your example): f4()-> f3()-> f1()-> ErrInvestmentLost Great, I'll handle this based on the fact that f1 was called by f3 (in the Java example, you'll just inspect e.getCause() until you reach the desired point in the trace - basically do what `printStackTrace()` but don't print it and instead do your error handling based on it). But nobody would ever want to do this because it's super brittle. I change f4 so that it first calls f17, which then calls f3, which then calls f17 again, which calls f1 and your error handling based on the call path is suddenly broken. What is it that you are trying to even achieve by doing this? Proper error handling doesn't depend on the call path. Proper error handling depends on the type of error that occurred and whether you can actually handle it at all or if you just have to give up and throw the error all the way to where it will get logged for a programmer to take a look at why it happened and why we couldn't handle it. Your claim about being able to handle "all stack traces" makes no sense to me. You don't handle stack traces. You handle error types. A real world example of the above (taking Java as an example again) might be a REST resource. My error handling should not depend on nor suddenly break, just because someone configured a new filter in the filter chain that sits above the actual resource method. Say someone added in a `AuthenticationFilter` that checks if some auth token is present and valid and that didn't used to be the case. Now any error handling in my resource method that was based on the exact stack trace combination that existed before that filter was added will break horribly.
- rmanolis 2y ago
  Odin can make stack traces as error types. Your system with Java will break if someone else add an AuthenticationFilter, but my system in Odin will not even compile until I have handled all the stack trace paths that include AuthenticationFilter. Do you see the differences between handling stack traces with union types rather than string?
  - tharkun__ 2y ago
    I don't see how it improves or gives me anything, no. See, the `AuthenticationFilter` sits outside of my REST resource. I could not care less that someone configured it and that at runtime, based on some configuration that can change without even needing a recompilation, this filter will either be there on the stack or it won't. My resource does not interact with this filter in any way and when an error happens somewhere down in another method I call, then I don't care that I was called with or without the auth token having been checked by said filter. I might care whether the method I called threw a `SQLException` or a `JSONParseException` but very probably I don't even care about that at all because I can't do anything specific in either case and will just throw it further (i.e. not handle it, other than potentially logging it). Java actually tried the whole "specify all error situations with checked exceptions and otherwise the code won't even compile" and it failed miserably and you are hard pressed to see anything new derive from `Exception`. Everyone uses `RuntimeException`. It does come at a cost, because now I no longer have the hassle of explicitly knowing and deciding what to do with these exceptions and I may only figure out that a particular type of error can happen once I "see it in the wild" (e.g. in my logs, coz something failed) or I'm lucky enough to have actually read the documentation and handled all the exceptions I wanted to handle. But that happened precisely because it was just too much to have all your code specify these exceptions when everyone figured out that 99% of all code just threw them further up the stack. You call one new library method that specifies an exception and you suddenly have to adjust 127 other files and the only thing you do is to declare all those methods will also just throw the exception further up the stack.
    - rmanolis 2y ago
      Odin's way does not mean that you have to do something for every Exception that is thrown to you. Also, in Odin SQLException can not exist, it is too generic, but SQLClosedConnException which is more specific can give a different story to a stack trace, which you can handle. For example, in Authentication_Filter_Error union, you will have another union called SQL_Verify_Account_Error, that it will contain SQL_Error enum with the Closed_Conn value. Imagine your stack trace like this Authentication_Filter_Error -> SQL_Verify_Account_Error -> SQL_Error.Closed_Conn Now when you know that can happen (through CDD), you can create a switch statement to catch the specific stack trace, to call the system administrator in the middle of the night to check what happens. This is how software should handle its errors and there is not even a need to log it. In your scenario, you wake up, you go to work, everyone is screaming at the office, you check the logs, you see the problem, and then you call the system administrator for the problem.

tharkun__ 2y ago

I looked at that and I find it pretty funny. As in, why would I ever build error handling that cares about the specific call stack to handle the error? That makes no sense to me. I'll show you why. Let's say you have the call stack as this (from your example): f4()-> f3()-> f1()-> ErrInvestmentLost Great, I'll handle this based on the fact that f1 was called by f3 (in the Java example, you'll just inspect e.getCause() until you reach the desired point in the trace - basically do what `printStackTrace()` but don't print it and instead do your error handling based on it). But nobody would ever want to do this because it's super brittle. I change f4 so that it first calls f17, which then calls f3, which then calls f17 again, which calls f1 and your error handling based on the call path is suddenly broken. What is it that you are trying to even achieve by doing this? Proper error handling doesn't depend on the call path. Proper error handling depends on the type of error that occurred and whether you can actually handle it at all or if you just have to give up and throw the error all the way to where it will get logged for a programmer to take a look at why it happened and why we couldn't handle it. Your claim about being able to handle "all stack traces" makes no sense to me. You don't handle stack traces. You handle error types. A real world example of the above (taking Java as an example again) might be a REST resource. My error handling should not depend on nor suddenly break, just because someone configured a new filter in the filter chain that sits above the actual resource method. Say someone added in a `AuthenticationFilter` that checks if some auth token is present and valid and that didn't used to be the case. Now any error handling in my resource method that was based on the exact stack trace combination that existed before that filter was added will break horribly.

rmanolis 2y ago
Odin can make stack traces as error types. Your system with Java will break if someone else add an AuthenticationFilter, but my system in Odin will not even compile until I have handled all the stack trace paths that include AuthenticationFilter. Do you see the differences between handling stack traces with union types rather than string?
- tharkun__ 2y ago
  I don't see how it improves or gives me anything, no. See, the `AuthenticationFilter` sits outside of my REST resource. I could not care less that someone configured it and that at runtime, based on some configuration that can change without even needing a recompilation, this filter will either be there on the stack or it won't. My resource does not interact with this filter in any way and when an error happens somewhere down in another method I call, then I don't care that I was called with or without the auth token having been checked by said filter. I might care whether the method I called threw a `SQLException` or a `JSONParseException` but very probably I don't even care about that at all because I can't do anything specific in either case and will just throw it further (i.e. not handle it, other than potentially logging it). Java actually tried the whole "specify all error situations with checked exceptions and otherwise the code won't even compile" and it failed miserably and you are hard pressed to see anything new derive from `Exception`. Everyone uses `RuntimeException`. It does come at a cost, because now I no longer have the hassle of explicitly knowing and deciding what to do with these exceptions and I may only figure out that a particular type of error can happen once I "see it in the wild" (e.g. in my logs, coz something failed) or I'm lucky enough to have actually read the documentation and handled all the exceptions I wanted to handle. But that happened precisely because it was just too much to have all your code specify these exceptions when everyone figured out that 99% of all code just threw them further up the stack. You call one new library method that specifies an exception and you suddenly have to adjust 127 other files and the only thing you do is to declare all those methods will also just throw the exception further up the stack.
  - rmanolis 2y ago
    Odin's way does not mean that you have to do something for every Exception that is thrown to you. Also, in Odin SQLException can not exist, it is too generic, but SQLClosedConnException which is more specific can give a different story to a stack trace, which you can handle. For example, in Authentication_Filter_Error union, you will have another union called SQL_Verify_Account_Error, that it will contain SQL_Error enum with the Closed_Conn value. Imagine your stack trace like this Authentication_Filter_Error -> SQL_Verify_Account_Error -> SQL_Error.Closed_Conn Now when you know that can happen (through CDD), you can create a switch statement to catch the specific stack trace, to call the system administrator in the middle of the night to check what happens. This is how software should handle its errors and there is not even a need to log it. In your scenario, you wake up, you go to work, everyone is screaming at the office, you check the logs, you see the problem, and then you call the system administrator for the problem.