2009/2/19 Radosaw Buat <radek.bulat / gmail.com>:
>
> It doesn't convince me. It can lead to bad programming style and could
> hide important error from programmer (the same goes to "blah() rescue
> nil" thing which should be used very very rarely). If programmer
> decide to raise some error it does mean that it's imporatnt and
> shouldn't be omitted. It also allow to continue when it shouldn't and
> give possibility to propagate error

yes, I am aware of "rescue nil" possibly hiding different error than
originally intended. That's another reason why a finer grained
approach that allows pointing to the exact place where the error is
expected would be useful.

>
> For example:
> @src = l.scan( /src="(.*)"/).quiet[0][0]
>
> How do you now if @src have "error" or good value? Ok, probably you
> check in next line if it's nil or something but if you won't then
> error can be propagated later.

The nil value of @src is a valid value in the case it was not
specified in the text.

>
> Exceptions have concrete reason to be in language like Ruby and giving
> more possibilities to omit them to programmer is bad idea.

Yes, exceptions have good reason, and so has catching them. If you
expect an exception can occur in a particular place in code you catch
it. You do not want your program to abort because of expected and
completely normal condition.

>
> PHP has something like '@'. It can be put before function name like:
> file = @fopen(...)
>
> It cause that php won't give any message about errors during execution
> this function.
> It sucks!

yes, it does. That's because these aren't exceptions, they are only
debug messages you can turn on or off.

Thanks

Michal