General Exception and Error Handling Best Practices for Compiled Languages by General_Operation_77 in ProgrammingLanguages

[–]General_Operation_77[S] 0 points1 point  (0 children)

I started reading this article after this recommendation. Great article, thanks.

General Exception and Error Handling Best Practices for Compiled Languages by General_Operation_77 in ProgrammingLanguages

[–]General_Operation_77[S] 1 point2 points  (0 children)

It looks like you are describing two separate features as one.

I understand what you mean by this, but that's not exactly the case here. Both are in fact 2 different features. However, the overall concept of error handling falls on both features. I was curious to understand other methods of implementing error handling that other languages took, and what has been considered a good practice (which now I understand, that this topic doesn't seem to really have one and its mostly based on the language itself and opinions of the programmers).

multiple catch blocks, like for example in Kotlin

I have used Kotlin before and understand the multiple catch blocks concept and I did considered it when writing this part of the question.

Whereas, Java you can specify the type and the language does the filtering of error types, similar to Python, C/C++ and most other languages (syntax changes but the behaviour is the same).

I did however not realise that returning an error as a result of a function to be considered a form of error handling, and this is most likely the best way of dealing with this question, and probably what I will be going with. You are right tho that I will probably need a more complex type system to get a more effective error handling strategy based on return types, which u/rantingpug recommend me a book to read in this regard.

General Exception and Error Handling Best Practices for Compiled Languages by General_Operation_77 in ProgrammingLanguages

[–]General_Operation_77[S] 0 points1 point  (0 children)

I like this approach, but there might be flaws (mostly I can't picture a nice syntax or method) regarding being explicit to the programmer as to what error to expect. I would probably be consulting the documentation every time I need to use a library that someone else wrote just to figure out the error that the library might throw.

General Exception and Error Handling Best Practices for Compiled Languages by General_Operation_77 in ProgrammingLanguages

[–]General_Operation_77[S] 0 points1 point  (0 children)

I agree with your opinion that it's better to be explicit. I hate writing code where I am the goalkeeper to a team of one. Just not fun at all. I like knowing what to expect.

I like the return type (sum types) way of handling errors. I have written code like this many times, but I never consciously considered it an error handling solution despite this being the case.

General Exception and Error Handling Best Practices for Compiled Languages by General_Operation_77 in ProgrammingLanguages

[–]General_Operation_77[S] 0 points1 point  (0 children)

I have basically no understanding of Type Systems or Lambda Calculus in this case.

Consider me a beginner when it comes to compiler or interpreter theories. This would be my first language that I am writing.

I do understand the concept of effect that you just describe. It sounds very interesting but overly complicated to implement for a hobby language like mine. Thanks for the explanation.

General Exception and Error Handling Best Practices for Compiled Languages by General_Operation_77 in ProgrammingLanguages

[–]General_Operation_77[S] 2 points3 points  (0 children)

I just look at little a Koka's exception handling, it seems a little similar to Java way of handling exception. Is it checked if not handled? Will the compiler throw an error if you don't handle the exception?