736766 - convert some 'int' functions in nsMsgSendPart.cpp to nsresult and cleanup their return values

Status: RESOLVED DUPLICATE of bug 779130

(MailNews Core :: Composition, defect)

Description

[:aceman]

There are some spots in mailnews/compose/src/nsMsgSendPart.cpp where a function is declared int but sometimes returns some negative 'status' and sometimes NS_ERROR_*.

I could try to clean it up, but need somebody to decide if this is wanted and which functions should be converted. If there isn't any reason they are done this way.

Comment 1

[Mark Banner (:standard8)]

It might be better to convert some of the char* members of nsMsgSendPart into nsCString, and then we end up with simple assignments with no raw string handling and we wouldn't have to deal with return results.

Comment 2

[:aceman]

Could you provide some example for this pattern?

Comment 3

[[e-mail]]

There is a lot of old-style char* string handling in nsMsgSendPart.cpp, which could be simplified by switching to nsCString, because it saves us from having to worry about freeing, copying or appending. This could then potentially remove all failure paths from methods that currently perform their own allocations. It therefore becomes unnecessary for the method to return a status code.

However, it is difficult to point to a particular example, as changing the type of a variable would involve a lot of code refactoring.

Comment 4

[:aceman]

Bug changes many problems with int/nsresult globally. After it is fixed, I'll see if there is anything left to be done here. I would not go into the string changes, I just try to convert all functions to nsresult and that they return valid NS_ERROR_* codes.

Comment 5

[:aceman]

The file looks basically done (all functions are nsresult and RETURNs have NS_ERROR_* values (or return values from other called functions).

I can do some cosmetic changes (like status -> rv, some line breaks after if) after the churn in the file settles :)

Comment 6

[:aceman]

I think global cosmetic fixes are not very wanted so I'll close this. The variable names can be fixed when the individual functions are touched in the future.

Comment 7

[:Irving Reid (No longer working on Firefox)]

OK.