ec_semvar:to_int shouldn't use catch about erlware_commons HOT 6 CLOSED

I disagree. We wanted to always use try in the book to show people the
more correct way of doing things. That said, catch is not deprecated,
and in my opinion is nicer in some instances because it makes for
fewer lines of code. Unless and until they depricate catch I think it
is quite valid.

On Fri, Apr 22, 2011 at 9:24 AM, ericbmerritt
[email protected]
wrote:

It should use try catch, and probably should be moved to a ec_int
module or something along those lines. At the very least it should be
moved to try catch.

Reply to this email directly or view it on GitHub:
#6

Martin Logan
Erlang & OTP in Action (Manning) http://manning.com/logan
http://twitter.com/martinjlogan
http://erlware.org

from erlware_commons.

its not depricated (though in my opinion it should be) its just heavily discouraged by the implementors. The reason its heavily discouraged and for very good reason. Its not selective, you catch everything regardless of whether you want to catch it or not, regardless of whether you can deal with it or not. Sometimes thats ok, sometimes its not, but you almost never know when its ok and when its no. So its best just not to use it, especially when there is a good construct that does the exact some thing in a more reasonable way. Its worth 3 (yes 3) additional lines of code to get rid of the ambiguity.

from erlware_commons.

That is the advantage of it. You often times do want to catch
everything, particularly in a dynamic language where exceptions thrown
are sparsely documented. Ideally it would be great to know exactly
what will come back and deal with each case accordingly. If you survey
the use of try though you will see many instances of

try
...
catch
_C:_E ->
...
end

Using catch in this case is more succinct.

On Sat, Apr 23, 2011 at 5:40 PM, ericbmerritt
[email protected]
wrote:

its not depricated (though in my opinion it should be) its just heavily discouraged by the implementors. The reason its heavily discouraged and for very good reason. Its not selective, you catch everything regardless of whether you want to catch it or not, regardless of whether you can deal with it or not. Sometimes thats ok, sometimes its not, but you almost never know when its ok and when its no. So its best just not to use it, especially when there is a good construct that does the exact some thing in a more reasonable way. Its worth 3 (yes 3) additional lines of code to get rid of the ambiguity.

Reply to this email directly or view it on GitHub:
#6 (comment)

Martin Logan
Erlang & OTP in Action (Manning) http://manning.com/logan
http://twitter.com/martinjlogan
http://erlware.org

from erlware_commons.

I can't think of a single case where you want to catch everything. It may appear that you want to catch everything, but you don't actually. Take the simple case of your to_int, what you really want to capture there is conversion errors. Do you want to also catch out of memory errors? do you want to catch possible exits (you have no clue what could be thrown under the covers after all), or any number of other things that could happen? no in the vast majority of cases no, you don't. Not only that but if you catch those errors it can cause unexpected behaviour in your system.

You have just done a great job of illustrating exactly why catch should be avoided in nearly every case. It does what you think you want it to do, not actually what you want it to do.

from erlware_commons.

As we spoke about on the phone we will agree to disagree on this.

On Tue, Apr 26, 2011 at 8:34 AM, ericbmerritt
[email protected]
wrote:

I can't think of a single case where you want to catch everything. It may appear that you want to catch everything, but you don't actually. Take the simple case of your to_int, what you really want to capture there is conversion errors. Do you want to also catch out of memory errors? do you want to catch possible exits (you have no clue what could be thrown under the covers after all), or any number of other things that could happen? no in the vast majority of cases no, you don't. Not only that but if you catch those errors it can cause unexpected behaviour in your system.

You have just done a great job of illustrating exactly why catch should be avoided in nearly every case. It does what you think you want it to do, not actually what you want it to do.

Reply to this email directly or view it on GitHub:
#6 (comment)

Martin Logan
Erlang & OTP in Action (Manning) http://manning.com/logan
http://twitter.com/martinjlogan
http://erlware.org

from erlware_commons.

ec_semver has been massively refactored. in the process, this issue no longer applies

from erlware_commons.