PL/SQL程序员的惯性思维？

jarwang

为什么这么多的PLSQL代码，都没有定义exception，没有rollback?

要么连exception都没写。
例：
create or replace procedure hek_test_p(Errbuf out varchar2,retcode out number) as
t_ex exception;
begin
insert into hek_test values(6790);
apps.Fnd_File.Put_line (apps.FND_FILE.OUTPUT, '提交1');
commit;
end hek_test_p;

要么就没有rollback。
例：
create or replace procedure hek_test_p(Errbuf out varchar2,retcode out number) as
t_ex exception;
begin
insert into hek_test values(6790);
apps.Fnd_File.Put_line (apps.FND_FILE.OUTPUT, '提交1');
commit;
exception
when others then
apps.Fnd_File.Put_line (apps.FND_FILE.OUTPUT, '出错');
end hek_test_p;


只有我有这个疑问吗?还是PL/SQL程序员的惯性思维？还是在ORACLE中事务、异常根本就不重要？

[ 本帖最后由 jarwang 于 2009-6-15 09:28 编辑 ]

sxlcom

这主要是看你的需求了,但一般都是要加你所说的一些东西的

jackywood

习惯问题

dingjun123

事务异常很重要，但是有时候业务需求，比如有很多步操作，一步失败则这个过程继续跑也没有意义，可以直接return，异常是有必要的!
有时候写的东西太多，大部分人为了完成任务，不会考虑这么细的，完成任务第一，以后的事以后再说，发现问题再解决，这是大部分人的思维和习惯，没有什么可争论的！如果你觉得你需要规范，那么保证你写的东西规范就行了，没有必要保证别人写的规范！

还有不规范的东西主要不是害自己，是害了以后维护你写的东西的人，那就是一个惨啊！我见过什么注释都没有的，连过程是干什么的都没有注释，文档都没有，只能从前台开始找，顺藤摸瓜来找这个过程什么意思，惨！

所以还是要规范，各种注释，文档，代码内部也要规范，这样别人维护起来就简单了，否则你挂了，你做的东西随你也一起离开了这个世界！

jarwang

谈到文档，那就介绍一下吧？

我的公司，现在的毛病就是通常是把简单的问题复杂化。本来是一个简单的问题，非得要折腾出N次会议。

然后呢？不该争论的争论，不该吵架的吵架。然后呢？一切还是再议？………

结果呢？这么不良代码就是不允许你动。

dingjun123

只能忍受了，既然改变不了，你就别参合他们的事算了，找机会离开，换个好点的地方

【风云】

否则你挂了，你做的东西随你也一起离开了这个世界！
这句话经典！

〇〇

inside vc++ 5的作者挂了,我还在看他的书

guostong

我们中的许多人编程只是为了生活，而且很多时候不是我们不想做得更好，而是许多原因不让我们做，宽容些吧。

lei

原帖由 jarwang 于 2009-6-15 10:33 发表
谈到文档，那就介绍一下吧？

我的公司，现在的毛病就是通常是把简单的问题复杂化。本来是一个简单的问题，非得要折腾出N次会议。

然后呢？不该争论的争论，不该吵架的吵架。然后呢？一切还是再议？………

结果呢？这么不良代码就是不允许你动。

老代码不能随便动的，尤其是维护了好多年的代码，都像密码一样了，肯定不能随便修改的
因为改代码设计到重新测试和重新发布问题，还涉及到管理和协调，这些都是需要考虑的
当然，条件具备的情况下，进行代码重构还是比较好的。
很多软件的生命周期太短，因此现实中代码质量一般也就得过且过了。