4 ms·

I highly recommend you to rethink error handling. No way to know if function throws exceptions, no way to know what kind of exceptions. This is a minefield.

by yyx 2mo ago

AbhiramaVS 2mo ago
I'm pretty sure I have exactly what you are talking about. error handeling was one of the things that I wanted to get right with jaithon, and I made my system similar to like rust. error[E0301]: cannot assign to immutable binding `x` --> examples/demo.jai:7:5 | 5 | let x = 1 | - `x` declared immutable here ... 7 | x = 2 | ^^^^^ assignment to immutable binding | help: change the declaration to `var x = 1` ^^ That was shown from the Readme, more extensive examples are in documentation! Is this what you were refering to or something else, I completely agree that erorr handeling is very important.
- mplanchard 2mo ago
  I think jyx was talking about the throw/try/catch mechanism[0] used for error handling, in contrast to error handling in e.g. Rust, where the idiomatic way of handling an error is to return a Result enum, containing either a success value or an error type. The latter allows callers to know that a function can error, and what kind of error it can return. Exception-based error handling, on the other hand, means you cannot tell by way of the type system whether or what errors a function can throw. [0]: https://github.com/abhiramasonny/jaithon/blob/main/LANGUAGE.md#errors https://github.com/abhiramasonny/jaithon/blob/main/LANGUAGE....
  - AbhiramaVS 2mo ago
    Ah yeah that makes more sense. Will look into this
program_whiz 2mo ago
AbhiramaVS I think your choice to use exceptions is fine, it matches closely with Java / Python your inspirations. The "show me every error" crowd loves to harp on this issue, but the truth is, its a tradeoff like all others. Exceptions provide flexibility in error handling, and most code just forwards and you end up in the same situation anyway. Something like this (go style): if result, err := do_thing(); err != nil { log.errorf("Got an error! %v", err); return err; } Or the rust equivalent isn't super useful, the code is just outputting an inferior form of stack tracing and debugging. Honestly unless the code at the immediate site of the error can handle the issue, or perhaps one level higher, having precise error information (usually obscured by some generic Error class anyway) isn't very helpful, and ends up propagating up to a high level where the whole thing is terminated / cleaned up anyway, which is what exceptions provide automatically. Also, only catching the things that you can deal with and know about is useful in the sense it keeps code flexible (e.g. you don't handle a DiskFull exception because the only thing you can do with it is throw anyway, and if you had a DiskFull error returned, you would just return it up the stack / panic). As new unhandled errors emerge, you just throw them up the stack, the same way error code would, except errors just require you to explicitly manage the machinery everywhere, requiring rigid, over-specified, fragile code in many cases. I do see the argument for explicit errors especially in system programming, realtime / perf-critical, kernels, etc. But this language doesn't appear to be targeted at that, and uses GC. So having exceptions seems like a valid design choice to me. Using them also frees you a bit since you can pass around functions, captured references, threads, etc. in a bytecode + GC lang without worrying to much about the error states and memory ownership.

I highly recommend you to rethink error handling. No way to know if function throws exceptions, no way to know what kind of exceptions. This is a minefield.

by yyx 2mo ago

I highly recommend you to rethink error handling. No way to know if function throws exceptions, no way to know what kind of exceptions. This is a minefield.

AbhiramaVS 2mo ago

I'm pretty sure I have exactly what you are talking about. error handeling was one of the things that I wanted to get right with jaithon, and I made my system similar to like rust. error[E0301]: cannot assign to immutable binding `x` --> examples/demo.jai:7:5 | 5 | let x = 1 | - `x` declared immutable here ... 7 | x = 2 | ^^^^^ assignment to immutable binding | help: change the declaration to `var x = 1` ^^ That was shown from the Readme, more extensive examples are in documentation! Is this what you were refering to or something else, I completely agree that erorr handeling is very important.

mplanchard 2mo ago
I think jyx was talking about the throw/try/catch mechanism[0] used for error handling, in contrast to error handling in e.g. Rust, where the idiomatic way of handling an error is to return a Result enum, containing either a success value or an error type. The latter allows callers to know that a function can error, and what kind of error it can return. Exception-based error handling, on the other hand, means you cannot tell by way of the type system whether or what errors a function can throw. [0]: https://github.com/abhiramasonny/jaithon/blob/main/LANGUAGE.md#errors https://github.com/abhiramasonny/jaithon/blob/main/LANGUAGE....
- AbhiramaVS 2mo ago
  Ah yeah that makes more sense. Will look into this

program_whiz 2mo ago

AbhiramaVS I think your choice to use exceptions is fine, it matches closely with Java / Python your inspirations. The "show me every error" crowd loves to harp on this issue, but the truth is, its a tradeoff like all others. Exceptions provide flexibility in error handling, and most code just forwards and you end up in the same situation anyway. Something like this (go style): if result, err := do_thing(); err != nil { log.errorf("Got an error! %v", err); return err; } Or the rust equivalent isn't super useful, the code is just outputting an inferior form of stack tracing and debugging. Honestly unless the code at the immediate site of the error can handle the issue, or perhaps one level higher, having precise error information (usually obscured by some generic Error class anyway) isn't very helpful, and ends up propagating up to a high level where the whole thing is terminated / cleaned up anyway, which is what exceptions provide automatically. Also, only catching the things that you can deal with and know about is useful in the sense it keeps code flexible (e.g. you don't handle a DiskFull exception because the only thing you can do with it is throw anyway, and if you had a DiskFull error returned, you would just return it up the stack / panic). As new unhandled errors emerge, you just throw them up the stack, the same way error code would, except errors just require you to explicitly manage the machinery everywhere, requiring rigid, over-specified, fragile code in many cases. I do see the argument for explicit errors especially in system programming, realtime / perf-critical, kernels, etc. But this language doesn't appear to be targeted at that, and uses GC. So having exceptions seems like a valid design choice to me. Using them also frees you a bit since you can pass around functions, captured references, threads, etc. in a bytecode + GC lang without worrying to much about the error states and memory ownership.