View mode: basic / threaded / horizontal-split · Log in · Help
January 30, 2012
Re: Chained Catch Statements
On Monday, 30 January 2012 at 19:25:03 UTC, Jesse Phillips wrote:
> On Monday, 30 January 2012 at 18:23:56 UTC, Era Scarecrow wrote:
>> try {
>> } catch (Throwable t) {
>>
>> } catch {Exception e) { //never executed
>>
>> } catch (StreamException st) { //never executed
>>
>> } //and the list can go on forever.
>>
>> See the problem?
>
> No?
>
> Error: catch at test.d(3) hides catch at test.d(4)
>
> The compiler does not reorder the exceptions because it 
> enforces order in the written code. As you say the compiler 
> knows the relationship, the one reading it may not.

So long as it errors from the hiding (as it appears it does) then 
it's fine, and the previous example shown was wrong.

>>> try {}
>>> catch (Exception e) {} // most throwable objects derive from 
>>> Exception
>>> catch (SpecialException e) {} // never used, because 
>>> Exception matches it all
January 31, 2012
Re: Chained Catch Statements
On 1/30/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
> If the compiler reorders the blocks for you

A warning, maybe. But I'm against compilers which try to be too smart
and rewrite code to change its semantics. If there's something wrong
with my code I want to know about it (warning or error) and fix it, I
don't want the compiler rewriting bad code behind-the-scenes. That
only encourages writing sloppy code, and I end up having to know
implementation details of each compiler to really know what some
function body actually does (it could be someone else's code and not
just mine).
January 31, 2012
Re: Chained Catch Statements
On Tuesday, January 31, 2012 01:05:20 Andrej Mitrovic wrote:
> On 1/30/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
> > If the compiler reorders the blocks for you
> 
> A warning, maybe. But I'm against compilers which try to be too smart
> and rewrite code to change its semantics. If there's something wrong
> with my code I want to know about it (warning or error) and fix it, I
> don't want the compiler rewriting bad code behind-the-scenes. That
> only encourages writing sloppy code, and I end up having to know
> implementation details of each compiler to really know what some
> function body actually does (it could be someone else's code and not
> just mine).

I see no reason why the compiler should be reordering anything here. That 
changes the semantics of the code. It's not like it's a great burden on the 
programmer to just reorder the blocks so that they're in the correct order. 
Having the compiler give a warning or error would be plenty, and a lot better 
than letting the programmer continue to screw up their code in ignorance. If 
they don't understand how the catch blocks work, they're likely to screw up 
more than just the order.

I do think that having the compiler complain when one catch block hides
another makes a lot of sense, but I think that that's as far as it should
go. It's the programmer's job to fix their code, not the compiler's.

- Jonathan M Davis
January 31, 2012
Re: Chained Catch Statements
Jonathan M Davis:

> I do think that having the compiler complain when one catch block hides
> another makes a lot of sense, but I think that that's as far as it should
> go. It's the programmer's job to fix their code, not the compiler's.

I agree. Do we create a new diagnostic enhancement request then?

Bye,
bearophile
January 31, 2012
Re: Chained Catch Statements
> I see no reason why the compiler should be reordering anything 
> here. That changes the semantics of the code. It's not like 
> it's a great burden on the programmer to just reorder the 
> blocks so that they're in the correct order. Having the 
> compiler give a warning or error would be plenty, and a lot 
> better than letting the programmer continue to screw up their 
> code in ignorance. If they don't understand how the catch 
> blocks work, they're likely to screw up more than just the 
> order.
>
> I do think that having the compiler complain when one catch 
> block hides another makes a lot of sense, but I think that 
> that's as far as it should go. It's the programmer's job to fix 
> their code, not the compiler's.

You are right.. I just have wishful thinking of the compiler 
being smart enough to auto-fix some things, but when you start 
making assumptions then errors and problems tend to arise more. 
That and if the compiler DOES reorder those blocks, then you 
re-ordering them for a specific reason may not work and could 
have unintended results. Course I don't see how with Try/catch 
since only one block (plus finally) can be used at a time.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home