D
dbeavon
Guest
On a practical level I agree with you (when using the CLR bridge, for example) . Especially since the "Progress.Lang.Error" appears to be the go-to exception that is raised for a variety of unrelated reasons. I will probably wrap CATCH-Progress.Lang.Error around any specific blocks of code that use the CLR bridge. (But I still wouldn't necessarily do this in every single entry-level procedure). On a theoretical level I strongly disagree with writing CATCH handlers for Progress.Lang.Error. Outside of our own AppError-derived errors, our custom programming doesn't necessarily have to be concerned with "system" errors that may be thrown. (Eg. out-of-memory exceptions, disk full exceptions, network disconnections, database unavailable exceptions, etc.) I've always heard that you should *only* catch exceptions that you know how to handle with your own custom code. Those types of "system" or "runtime" errors are interesting, but only insofar as I want their details for post-mortem analysis. There is very little that an ABL programmer can do to mitigate the problem if the OS itself (or the runtime) has decided to turn against you. And yes, in theory it can be harmful to CATCH errors and handle them in a poor way. For example, if you are already out of disk space and your catch block is written to write a lot of additional information to the disk, then that error handling can be counter-productive and it might even obscure the original error. Similarly if the network fails and your error handling involves trying to use the network, then that is counter-productive for the same reasons. These are fairly extreme examples, because we are talking about fairly unexpected errors.
Continue reading...
Continue reading...