5 ms·
_For good error reports back to the user, you'd have to have a fairly large amount of logic in the catch block._ Serious question. How is that a reason to have
by vrotaru 14y ago
_For good error reports back to the user, you'd have to have a fairly large amount of logic in the catch block._
Serious question. How is that a reason to have that _amount of logic_ in the function body?
Having IDE/editors which can fold blocks of code and having the catch blocks collapsed by default will make code reading/understanding of code easier. IMO.
Actually, I may try something like makng the try-cacth the body of the function on a small to medium size project just to see the tradeoffs.
- viraptor 14y agoI think that putting it in the body actually reduces the amount of code and makes it more readable. Compare something like this (ignoring naming, formatting, made up language, etc. I want to show the structure only): fin=open(fin_name) fout=open(fout_name) ... catch IOError e if e.call == 'open' if e.filename == fin_name log_error "cannot open input ..." elif e.filename == fout_name log_error "cannot open output ..." else log_error "cannot open file, but filename unknown" elif e.call == ..... ..... to something like this: try fin = open(fin_name) catch IOError log_error "can't open input ...." return try fout = open(fout_name) catch IOError fin.close() log_error "can't open output ...." return Both are ugly, but I really wouldn't like to be the person trying to match up the error handling from the first example to the exact places in the function body. I'm not even sure what would this look like if the exception was coming from somewhere deeper in the function. open() is easy because we know how it fails. More complex call chains would be a challenge to even match up to the place they happened.