"Failed: unknown reason"
That is exceptionally poor programming. You know I exactly what caused the error. It's just bad practice to not convey that properly in your errors.
@johnaldis or printing "error, thing returned null". The programmer tested for null, therefore they know what is and isn't expected.
@quixoticgeek I see what you mean… I’ve also seen code which caught exceptions, and then threw its own, less descriptive, exception to the next layer…
Error handling in most languages (e.g. Java and JavaScript) is horrible, with errors of any arbitrary type potentially occurring at any arbitrary moment.
If you want errors to be predictable enough that applications can make sensible error messages out of them, you want those applications to be written in something like #Rust.
@argv_minus_one I've never had an issue with it writing in C for 25 years. Likewise Java for slightly less time.
You do something. Check for the error condition, and if you have one you can exit with an error message saying as such. Just "an error occured" is lazy programming.
You can reliably say what you were trying to do when the error occurred, true, but that's not the same thing as giving a good quality explanation of the error that occurred, and how can you prepare such an explanation when you catch an exception of some unknown arbitrary type?
@argv_minus_one "error trying to do $thing."
Still more useful than just "unknown error"
@quixoticgeek Chances are the person who wrote a message with “unknown reason” was doing so because the thing *they* called just returned null. They had the choice between telling you “unknown reason” or… crashing?